lewo
Joined 6 years ago
Karma
39
Submissions
21
Member since
Jan 2
https://lewo.abesis.fr
View on Hacker NewsRecent submissions
Comment · 1 month ago
Another way to fix this kind of issues would be to fallback on the Software Heritage which archives the whole GitHub.
This is something Nix and Guix are trying to achieve: by default, they fetch source code from the original endpoint, but if it doesn't respond anymore, they would query the Software Heritage archive [1].
Because go mod doesn't use SHA, it makes things a bit more complicated but Nix/Guix encountered the same issue and there are some mechanisms to workaround this issue.
[1] https://www.softwareheritage.org/2025/05/21/software-heritag...
Comment · 2 months ago
> AI isn’t a chef. At best, it’s a steak machine.
Seems this analogy is also correct regarding our climate!
Comment · 5 months ago
On the other hand, the TPM spec is pretty complex, especially because they wanted to address privacy issues: the endorsement key, burned by the manufacturer, is only able to encrypt messages and not able to sign them, because this could have been used to track machines. (and this makes a remote attestation protocol much more complex to implement)
So, it looks like they were aware about such kind of issues and tried hard to mitigate them.
Comment · 8 months ago
Definitely not.
But when someone looks at me, my gaze is drawn to that person, to say "hello" for instance. I have the same kind of feeling with a camera.
(Maybe if i was living in a town, i would loose this reflex.)
Comment · 8 months ago
On the french trains, you can sit opposite someone else. I'm feeling really uncomfortable when this person scrolls on its phone, with the phone back camera pointing to me for hours.
I sometime ask this person to hide the camera and they generally understand my feeling.
Comment · 10 months ago
I think this is really close to the way nix2container works (https://github.com/nlewo/nix2container). nix2container generates metadata at build time and streams the required data at runtime.
At build time, it generates a JSON file describing the image metadata and the layers data location. At runtime, it consumes this JSON file to stream layer data and image configuration to a destination. This is implemented by adding a new transport to Skopeo. Thanks to this implementation, nix2container doesn't need to handle all various destrination since this is managed by Skopeo itself.
Recently, we introduced a mechanism to also produce such kind of JSON file for the base image (see https://github.com/nlewo/nix2container?tab=readme-ov-file#ni...).
I'm pretty sure the added (not usptreamed yet) transport could be useful in some other close contexts, such as Bazel or Guix.
I'm the nix2container author and i will be glad to discuss with you if you think this Skopeo transport could be useful for you!
(btw, your blog post is pretty well written!)
Comment · 11 months ago
In the same kind of spirit, when i was the tech team manager in a company without any transparent salary policy, i've been practicing what i've been called the "symmetrical salary management": when I knew the salary of a managed team colleague, i told him/her my salary. I also asked to keep my salary private, as I kept their salaries private.
I think this is a pretty important requirement to build trust in a team.
Comment · 11 months ago
More precisely, this is the price per person but if you travel alone, you have to share a room with someone else. Or you would have you to make private a double room which costs about 5400E.
Comment · 1 year ago
> With no way of splitting up the Nix dependencies into separate layers
nix2container [1] is actually able to do that: you can explicitly build layers containing a subset of the dependencies required by your image. An example is provided in this section: https://github.com/nlewo/nix2container?tab=readme-ov-file#is...
For instance, if your images use bash, you can explicitly create a layer containing the bash closure. This layer can then be used across all your images and is only rebuild and repushed if this bash closure is modified.
> > pull in dependencies often results in massive image sizes with a single /nix/store layer
This is the case for the basic nixpkgs.dockerTools.buildImage function but this is not true with nix2container, nor with nixpkgs.dockerTools.streamLayeredImage. Instead of writing the layers in the Nix store, these tools build a script to actually push the image by using existing store paths (which are Nix runtime dependencies of this script). Regarding the nix2container implementation, it builds a JSON file describing the Nix store paths for all layers and uses Skopeo to push the image (to a Docker deamon, a registry, podman, ...), by consuming this JSON file.
(disclaimer: i'm the nix2container author)
Comment · 1 year ago
And regarding this part of the article
> Particularly with GitOps and Flux, making changes was a breeze.
i'm writing comin [1] which is GitOps for NixOS machines: you Git push your changes and your machines fetch and deploy them automatically.
Comment · 1 year ago
> Would Nix work well with GitHub Actions?
You can use Nix with GitHub actions since there is a Nix GitHub action: https://github.com/marketplace/actions/install-nix. Every time the action is triggered, Nix rebuilds everything, but thanks to its caching (need to be configured), it only rebuilds targets that has changed.
> How do you automate running tests and deploying to dev on every push
Nix is a build tool and it's main purpose is not to deploy artifacts. There are however a lot of tools to deploy artifacts built by Nix: https://github.com/nix-community/awesome-nix?tab=readme-ov-f...
Note there are also several Nix CI that can do a better job than a raw GitHub actions, because they are designed for Nix (Hydra, Garnix, Hercules, ...).
Comment · 2 years ago
We have an issue to support non flake deployments: https://github.com/nlewo/comin/issues/30
Comment · 2 years ago
No, it has been initially developed to manage a "COMmunity INfrastructure" and it sounds like the word "coming". I didn't know this meme but it's a nice coincidence because this infrastructure is actually a kind of "CHATONS" [1] (kitten in french)!
Thx for the ref which could be useful for a future logo!
Comment · 3 years ago
The main issue is to use configuration files residing somewhere in the filesystem. This looks like a global variable in a codebase (something we generally try to avoid).
Instead, the configuration file should be explicitly provided as a command line argument. Systemd sandboxing can also be useful to ensure the program only uses the expected set of files.
For instance, on my NixOS machine, the Nginx configuration is not in `/etc/nginx` but explicitly provided and can then be known with ps:
$ ps aux | grep nginx
nginx: master process /nix/store/9iiqv6c3q8zlsqfp75vd2r7f1grwbxh7-nginx-1.24.0/bin/nginx -c /nix/store/9ffljwl3nlw4rkzbyhhirycb9hjv89lr-nginx.conf
Comment · 3 years ago
> would be hard to beat "sync a file to a warm container and run it"
It depends on the size of your Pex file (i don't think you mentioned it and sorry if i missed the info). With a Docker/OCI image, it would be possible to create a layer with only the Python files of your application (without deps and interpreter). (I say "would be possible" because that's currently not easy to achieve with Nix for instance.)