undefined | Better HN

0 pointsjustinsaccount8y ago0 comments

> With Guix you get full introspection of your entire package dependency graph

Yes, I know all that. It's neat. I would like to learn more about it.

> The simplest way would be to package the app for guix

I was asking how to package the app for guix, and your response is the simplest way would be to package the app for guix...

> If you need a vm or soimilar though I'd translate your example above into a system config where: - packages include python-2.7 and whatever is in requirements.txt (this may mean you have to package a few things, but again this is usually super easy) - users and groups are added to the config, as they always are, no extra step necessary. - exposing ports and networking is available as options for qemu script guix produces to launch the vm. - CMD ./notify.py: create a "simple" service that can be autostarted by the system on boot. - filesystem access is also handled by arguments to the qemu script.

Yes, I'm sure it is super easy. How do I do it?

Do you know how to use the dockerfile I posted above? You run

  docker build -t myapp .
  docker run myapp

that's super easy. 9 lines and 2 commands. You can now add docker expert to your resume.

> Zeromq and libsodium are already packaged on guix, czmq and zyre looks like they would be simple to package,

Well, I was working on a fork of things, so I would have needed to install my forks.

> guix is really quite simple to work with

I'm sure it is!

> And pointless, come on - what does that even mean? Does it mean you don't value them? I was quite happy to read about a neat new thing I can use my favorite tool for.

You are correct, I don't really value posts saying how cool and easy something is and how much better it is than other solutions, when they don't actually present a complete solution someone can actually use.

I get that it is not other peoples job to teach me how to use something like guix, but do people not understand why things like Docker won?

0 comments

5 comments · 1 top-level

t0nt0n8y ago· 4 in thread

Right, your dockerfile contains a requirements.txt with unknown complexity and number of packages, your app is without a name and does not have any links to code.

I'd be happy to provide some examples. Say you want your fork of libsodium:

  (define-public my-libsodium
    (package
      (inherit libsodium) ; now anything not defined in this package will be inherited from libsodium
      (source (origin (method url-fetch)
                (uri "url-to-your-sources")
                (sha256 (base32 "hash"))))
     ; Add whatever other fields your fork needs.
  ))

Sure it's slightly more verbose. That's a bit of the cost of having something you can actually rely on, with that degree of hackability.

If you actually want help to package these things ask on our mailinglist or IRC, we're happy to help with specifics. But you're basicly complaining that I didn't give you a concrete solution to a problem with several missing details that are important. Docker would not be able to instantiate your python project if it did not know the contents of your requirements.txt.

The thing is docker is huge and bloated; is far from secure, and will probably stay that way for the foreseeable future; has a more or less complete lack of introspection; and is not strictly reproducible (sure, it gets quite far along the way, but it really is not).

Guix on the other hand is rather lightweight, and you have a fair amount of control over how lightweight it should be; builds from source, and has a sort of hotpatching system for security fixes; has introspection and is quite close to bitreproducible.

Sure, docker is _easy_, as long as it works. And I'd argue that because of its complexity and obscurity it is not practically free software.

cyphar8y ago

Regarding your concerns about Docker, I agree with that (even though I've been working on Docker and in the wider container community for almost 5 years now). However, there are plenty of tools that are compatible with Docker but provide similar benefits.

For instance, (from the openSUSE community which I'm a part of) we have KIWI that provides builds with full introspection on a package level (similar to what you're doing with Guix). If you build the image inside OBS (our build system) then if a dependency of your image is updated then your image will be rebuilt automatically and published in OBS (where it can be further pushed to any Docker/OCI registry you like). The packages are signed, and the image is also "signed" (though it currently signs the image artifact and doesn't use image signing since that is still not standardised). And most packages in openSUSE are bitreproducible (we build everything in OBS).

The above is far and above much better than the current standard in the "official" world of Docker, but unfortunately because OBS has a UI from the early 2000s (which is when it was written) it doesn't get enough attention outside of the communities that use it (and enjoy using it a lot). Everyone wants Dockerfiles even though they cannot provide these features (and you cannot get package manifests of your images without running a package manager in the image, which means you cannot get vulnerability information from the manifest).

[ Though I'm mostly talking about openSUSE here, I also happen to work for SUSE on the containers team. ]

pxc8y ago

> However, there are plenty of tools that are compatible with Docker but provide similar benefits.

And Guix is one of them, remember? From the article:

> Add -f docker [to your `guix pack` command] and, instead of a tarball, you get an image in the Docker format that you can pass to docker load on any machine where Docker is installed.

:-)

> The above is far and above much better than the current standard in the "official" world of Docker, but unfortunately because OBS has a UI from the early 2000s (which is when it was written) it doesn't get enough attention outside of the communities that use it (and enjoy using it a lot).

This is so true! I've mostly moved on from traditional, imperative package managers and associated distros in favor of the functional package management paradigm exemplified by Guix, but I still recommend openSUSE to my friends who prefer a more traditional/mainstream distro because of the love I have for the Open Build Service and Zypper.

The web interface for OBS does feel clunky these days, but it's a wonderful tool not just for improving the reliability and quality of software packages, but distributing them. Zypper is hands-down the most powerful and complete high-level package management tool I've ever used as part of a binary-based GNU+Linux distro. I love that openSUSE provides an instance of OBS that anyone can use for free to build packages for not just openSUSE but a TON of different distros.

I wish more people would explore, take advantage of, and celebrate OBS just like I wish they'd do the same with Nix and Guix!

justinsaccountOP8y ago

I don't think that's very verbose. The dockerfile I was using to build the app basically grabbed a specific version of all the deps and ./configure && make install'ed each one.

I'm completely onboard with the idea of reproducible builds.

> The thing is docker is huge and bloated; is far from secure, and will probably stay that way for the foreseeable future

It would be a mistake to fully associate container workflows with docker itself.

https://github.com/genuinetools/img + https://github.com/opencontainers/runc can be used to provide almost the same workflow as docker, without using docker itself.

You could also use the '-f docker' option the post talks about with runc to run the resulting image in an unprivileged container.

masklinn8y ago

> It would be a mistake to fully associate container workflows with docker itself.

It would also be a mistake to fully associate Docker containers with Docker.

Joyent can run docker containers, securely (zone-isolated), on smartos.

j / k navigate · click thread line to collapse