ryangibb

You mean like endorsement? https://info.arxiv.org/help/endorsement.html

As far as I can tell, checking for proc macro crates by suffix, only one: ergol -> ergol_proc_macro with >=0.0.1, <0.0.2.

I didn't include singular dependencies in this grep (=) just upper bounds (< and <=).

Some rough scripting is telling me there's over 600,000 singular dependencies of which just under 10,000 are proc-macro pairs.

there's nothing stopping you from pulling in every single dependency of every dependency

It depends on the exact system; for example npm's peer dependencies means we can reduce from SAT to npm.

But if there is no such functionality (e.g. just the concurrent package calculus with g(v)=v) they yes, I agree.

(author here) I also gave a talk on this work at FOSDEM this year: https://watch.eeg.cl.cam.ac.uk/w/iPX1Xx8LAZnuhojVYbyvAB

Presumably you mean compatible rather than incompatible there?

I've edited for clarity, I mean "because packages with different major versions should have incompatible APIs anyway."

While you can specify upper bounds for the depdnency ranges, that is extremely uncommon in practice.

In https://github.com/rust-lang/crates.io-index I count just under 7000 upper bounds on dependency ranges that aren't just semver in disguise (e.g. not ">=1.0.0, <2.0.0"):

    $ rg --no-filename -o '"req":"[^"]*<[^"]*"' . | grep -Ev '< ?=? ?([0-9]+(\.0){0,2}|0\.[0-9]+(\.0)?)"' | wc -l
    6727

(author of the paper here)

My sibling makes a great point about type errors: did you know Cargo (Rust) only supports diamond dependencies where the versions differ only in major version[^0]? So you can have exactly the same problem with B depending on D@v1.1 and C depending on D@v1.2 in Cargo. I believe the reason for only supporting concurrent versions with different major versions (to use the paper's parlance) is because packages with different major versions should have incompatible APIs anyway.

[^0]: Or 0 major version and differing minor version -- Cargo has it's own definition of semver incompatible

... and it becomes a pseudo SAT problem in some cases if you want optimal dependency resolution

A couple of clarifications: many dependency resolution algorithms are essentially SAT even if they support concurrent versions (see Cargo). Section 3.3 of the paper might be an interesting read -- it discusses the spectrum of complexity in the problem of dependency resolution, and why some ecosystem's approaches don't work for others. Also, it's generally a 'pseudo SAT problem' (i.e. NP-complete and can be reduced to SAT) to find any valid resolution, not just an optimal one.

This is the core algorithmic and architectural limit on package managers. Almost everything else is just implementation and engineering details.

I agree, and that's why the paper focuses on the semantics of dependency expression and dependency resolution! But there's a lot more than concurrent versions in the semantics of how package managers express and resolve dependencies, i.e. features, formula, peer dependencies. The point of the paper is that there's a minimal common core that we can use to translate between package management ecosystems, which we're planning on using to build useful tooling to bridge multilingual dependency resolution.

What does NAT do for security that a firewall doesn't?

E.g. DNS-Based Authentication of Named Entities? https://www.rfc-editor.org/rfc/rfc6698

There's a TLSA resource record for certificates instead of a TXT encoding.

As far as I know no major browser supports it, and adoption is hindered by DNSSEC adoption.

The MirageOS project [0] is a great collection of functionality pure OCaml libraries that are useful outside of unikernels. I've used the DNS library with an effectful layer for various nameserver experiments [1].

[0] https://mirage.io/

[1] https://ryan.freumh.org/eon.html

Author of Eon here, there's still some open questions I have here about managing the lifetimes of these certificates. Renewal is supported via a Capnproto callback and there's some ad-hoc integration in with NixOS nginx to restart it on a certificate renewal. https://github.com/RyanGibb/eon/blob/3a3f5bae2b308b677edfb3f...

This doesn't work in the general case, e.g. for postfix and dovecot, and is only becoming more pertinent with short lived certificates. It would be great if the service manager could use these capabilities directly. I think GNU Shepard's integration with Guile Goblins and OCapN is a step in the right direction here: https://spritely.institute/news/spritely-nlnet-grants-decemb...

I've written a little more about this here: https://ryan.freumh.org/eilean.html

Many Circassians settled in Jordan, refounded Amman, and to this day the King of Joran has a Circassian Bodyguard.

This is a good argument for the Unix philosophy's "do one thing" to avoid the bloat the author describes. E.g. vi, sendmail, and some bash for Word's mail merge. Or Emacs and some lisp. But then the onus is on the user to compose these tools to something that solves their particular problem.

I've got a small project that uses a Cap'N Proto capability to do the key exchange for a mosh session which might be interesting to some: https://github.com/RyanGibb/capability-shell/blob/619d26dbb1...

Ely (a few miles south of this project) used to be an island with a large eel fishing industry, from which it derives it's name. The Fens were drained in the 17th century with help from Dutch engineers, and I believe much of the area is now below sea level; the river Ouse is raised above the surrounding land with embankments. I've ran past some of the pumping stations on the Roman lodes myself: https://www.openstreetmap.org/way/125065713

I wonder what the risk is of rising sea levels to this project?

The second I stepped outside I was set upon by a flood of mosquitos like I have never experienced before. I have been to the jungles of Vietnam, the swamps of Florida and the Canadian countryside. This was beyond anything I've ever experienced.

There are bugs in my mouth, ears, eyes and nose almost immediately. The photo below is not me being dramatic, it is actually what is required to keep them off of me.

In fact what you need to purchase in order to walk around this area at all are basically bug nets for your face. They're effectively plastic mesh bags that you put on.

This is pretty standard for Scotland in the summer too.

The difficulty with the GNS is getting the public keys that enable the decentralisation. Key signing parties seem to have their limits.

There’s a bunch of alternative DNS roots out there, that are similarly hierarchical, but really interesting: https://en.wikipedia.org/wiki/Alternative_DNS_root#Implement...

Given the website, is worth noting that keyboards like this can avoid the infamous Emacs pinky. I've got the keys two rows below the homerow bound to the modifiers right alt, super, alt, control, and shift. And reversed on the other hand. This makes any modifier shortcuts very ergonomic -- one hand 'chords' the modifiers and the other hits the non-modifier key.

I built similar functionality into a DNS server so the device can be woken from beyond the local network: https://github.com/RyanGibb/eon/tree/main/bin/hibernia

There's a bit of a writeup here: https://www.sicsa.ac.uk/wp-content/uploads/2024/11/LOCO2024_...

It's very rough, and I haven't found much time to work on it recently, but I've started something with https://github.com/RyanGibb/eilean-nix

Vernor Vinge wrote about 'programmer archaeologists' digging through 1000-year-old software stacks in https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...

When does the determinism happen?

When I specified packages to install, I didn’t specify an integrity hash, let alone a version number. If I ran the same Nix configuration a year from now, I assume I’d get a different system because it would install different versions of the vim and curl packages I specified.

That would be from the Nixpkgs [0] instance obtained from a Nix channel [1].

Nix flakes [2] provide an alterative way to specify inputs which pin them in a `flake.lock`. This allows things like Nix expression caching due to hermetic evaluation (as opposed to just builds being hermetic).

[0] https://nixos.org/manual/nixpkgs/stable/

[1] https://nixos.org/manual/nix/stable/package-management/chann...

[2] https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...

For full NixOS on an android device, something more like postmarketOS, see also https://mobile.nixos.org.

While it might be possible, it's not very practical.

The original Nix thesis [0] talks about using Nix as a low-level build system in Chapter 10.1. And the author of opam-nix* has made an attempt to use Nix as a build system [1]. However, dune is a complicated bit of software that's not easy to replicate, and Nix isn't particularly well suited to the task.

[0] https://edolstra.github.io/pubs/phd-thesis.pdf

[1] https://gitlab.com/balsoft/tumbleweed

*Which is essentially functionality to use Nix as a dependency manger with opam-repository.

I self host a mailserver on a hetzner VPS running NixOS using nixos-mailserver [0] (dovecot and postfix under the hood).

[0] https://gitlab.com/simple-nixos-mailserver/nixos-mailserver

Feeder: https://f-droid.org/en/packages/com.nononsenseapps.feeder/

One of the surprisingly few readers I could find that is local-only and doesn't require an account.

I self host a lot of services but don't see the need for an RSS reader server-side.

While this will aid usability, I think it's a symptom of a harder problem: the composition of configuration for different services.

My approach for DNS is to use a NixOS module that describes the configuration of a zonefile [0]. Then, for example, to add an MX record for the root pointing to the `mail` subdomain, one can do:

  dns.records = [
    {
      name = "@";
      type = "MX";
      data = "10 mail";
    }
  ];

This has the advantage that comments and any other metadata to be included can be added here, the configuration can be version controlled and merged/reverted as appropriate, and that the DNS records for services can configured right alongside them.

It has it's limitations though. There may be implicit dependencies in the runtime of different services. It's hard to test because of this.

[0] https://github.com/RyanGibb/eilean-nix/blob/0b4213b0/modules...

[1] https://github.com/RyanGibb/eilean-nix/blob/0b4213b0/modules...

[2] https://github.com/RyanGibb/eilean-nix/blob/0b4213b0/modules...

Make sure you're using the most recent version. It should be present in v1.1.8.

I think the parent comment was referring to blocking access to other server instances rather than blocking individual users.

Overzealous spam filters seem like the email equivalent. I have reoccurring issues trying to get self hosted email received by GMail/outlook addresses. Although these filters are an impersonal corporate policy rather than up to an individual instance admin's discretion.

Got it, thanks.

the no true scotsman defense

How is this a 'no true scotsman' defense? I don't see the relevance.