Update (1 October 2026). The Kayros paper is now available in its second arXiv version. The links below point to v2.

Kayros: the solver and its evaluation

The Kayros paper presents an open-source solver that produces improving solutions during a run and can also issue computational optimality certificates under explicit assumptions. It develops the treatment of time-dependent arrival functions and evaluates the anytime and exact components on published routing instances. On a campaign of 212 instances from five families, with a one-hour single-threaded budget, Kayros achieves a pooled anytime score 63.3% lower than Timefold, the strongest of the three available contenders in that comparison. The paper also reports 704 published computational certificates as of 8 August 2026. Those certificates cover particular instances under the paper’s stated protocol, not every benchmark family or instance size.

The companion anytime evaluation paper examines how to compare solvers that may find a first feasible solution at different times and then continue improving it. It develops a normalized signed primal integral (Λ), including a defined score for runs with no valid incumbent and a way to retain improvements below a frozen reference value. Its v2 analysis remeasures the descriptive time-sliced Hexaly arm and two model-fidelity ladders through the C++ binding at 10 seeds. This paper gives the measurement choices behind the Kayros comparison their own examination.

Benchmarks, certificates, and thread scaling

The Kayros technical report describes the solver and the verification process behind its public results. It documents the integration of the measured-traffic Blauth2024 family and the construction of Poryos2026, whose real road networks are combined with controlled synthetic congestion. The report’s v2 also records the retraction and repair of earlier invalid certificate claims. Kayros improved the 30 imported high-effort Blauth2024 references at unchanged route counts, but does not claim an optimality certificate for that family.

The separate Hexaly experimental report asks how thread count affects two TDVRPTW model encodings through Hexaly’s C++ binding. One encoding evaluates continuous travel-time functions through external callbacks, while the other uses time slices evaluated by the solver. Across its 10-instance, 10-seed study, the time-sliced encoding benefits more consistently from additional threads. These are results for the tested models and instances, rather than a general ranking of the encodings or solvers.

The papers and reports can be read independently. Together they make the solver’s claims, the scoring method, the benchmark data, and the comparison conditions available for inspection. The publications page lists their full citations, while the earlier Kayros and Poryos2026 announcement gives the original release context.

The MAMUT-routing catalog has a new family, and it is a significant one. Blauth2024 is our faithful conversion of the vrptdt-benchmark published by Jannis Blauth, Stephan Held, Dirk Müller, Niklas Schlomberg, Vera Traub, Thorben Tröbst and Jens Vygen (University of Bonn) alongside their paper Vehicle routing with time-dependent travel times: Theory, practice, and benchmarks (Discrete Optimization, 2024). It is now live on my mirror: mamut-routing.onyr.net/benchmarks/tdvrptw/blauth2024.

Why this benchmark matters

Most time-dependent routing benchmarks generate their congestion synthetically. The Bonn group did something different: they built travel times from real OpenStreetMap road networks combined with measured Uber Movement speed data, for ten cities on four sub-continents (Berlin, Cincinnati, Kyiv, London, Madrid, Nairobi, New York, San Francisco, São Paulo, Seattle) at 10, 500, 1000 and 2000 customers. The result is, to my knowledge, the most realistic public TDVRPTW benchmark available today.

There is also a preservation angle. Uber Movement was shut down on October 1, 2023, so the published arrival-time matrices can no longer be reproduced: they are the sole surviving artifact of that speed data. Redistributing them faithfully, with checksums and a documented format, is a way to make sure they stay usable.

What the instances look like

The family covers the delivery-only variant of their benchmark: an unlimited fleet of identical uncapacitated vehicles, depot departures at or after 15:00 with free return, three minutes of service per delivery, and hard time windows (half one-hour windows, half a wide 15:30 to 21:00 window). Travel times are dense per-arc piecewise-linear arrival-time functions spanning 15:00 to 22:00. The upstream pickup-and-delivery variant is out of the catalog’s node-routing scope and stays upstream only; there is also no time-window-free twin, because the time windows are intrinsic to how the instances were generated.

Conversion choices

The port is a value-exact relabeling, not a numeric transformation. Two choices are worth spelling out:

• Integer milliseconds. This is the first family in the catalog whose time unit is integer milliseconds rather than seconds, declared per instance. The reason is bit-exactness: 91% of the upstream breakpoints are not whole seconds, so any rescale would have broken the exact correspondence with the original data.
• A new objective, FleetCostDuration. The upstream objective charges $200 per vehicle plus $20 per working hour. We added native support for it in the catalog’s format and reference checker: cost = sum of per-route optimal durations + 36000000 ms per route, so that the cost in dollars is exactly the cost in milliseconds divided by 180000. Costs map to their published dollar values exactly, without any epsilon.

Hosting is hybrid because a single n=1000 arrival-time-function sidecar exceeds GitHub’s file-size limit (the n=2000 ones reach 386 MB gzipped). The 10 and 500 customer tiers are hosted in full in the satellite repository; the 1000 and 2000 customer tiers host the instance descriptors and best-known solutions, while the oversized sidecars regenerate deterministically from the upstream GitLab data via a published converter, verified against published SHA-256 pins. Two independent conversions on different machines produce bit-identical files.

Best-known solutions, verified before import

At the time of import, the family shipped with 40 best-known solutions, one per instance:

• 30 imported reference solutions from the authors’ BonnTour solver in high-effort mode, covering every city at 500, 1000 and 2000 customers, credited to their team. Before import, every solution was re-evaluated hard-time-window-feasible with the upstream evaluator’s own exact rational arithmetic, then repriced by our reference checker. As a cross-check, the published dollar values of the paper’s Table 2 are exactly the ceilings of the imported costs, thirty for thirty.
• 10 first-published solutions at n=10, where upstream publishes no solutions. These came out of a first Kayros solver campaign on the family; every city converged to a bitwise-identical best value on 20 independent seeds, which makes them strong candidates for the true optima.

License

Unlike most of the catalog, this family is distributed under CC BY-NC 4.0: the underlying Uber Movement speed data is CC BY-NC 3.0, so every instance and solution file is non-commercial use only, with attribution to the original authors, their repository and the bonndata archive. The full attribution block ships in the satellite repository’s LICENSE.

How it relates to Poryos2026

Readers of my Poryos2026 announcement may wonder how the two families relate, since both build their travel times on real OpenStreetMap road networks. Poryos2026 is in fact inspired by the Bonn benchmark, and the two are complementary rather than competing.

• Poryos2026 is designed for comparative studies across the whole problem chain: CVRP, VRPTW, TDVRP and TDVRPTW instances share the same underlying networks and customer locations, so you can measure exactly what adding time windows or time dependence costs. Its congestion comes from traffic models applied to the road networks, and it ships under ODbL.
• Blauth2024 is designed for real-world time-dependent benchmarking, with a level of realism Poryos2026 cannot match: its congestion is measured, not modeled, since the Bonn group had access to Uber Movement speed data. The trade-offs are a single problem variant (delivery-only TDVRPTW), a non-commercial license inherited from that data, and travel times that can no longer be regenerated from public sources.

In short: Poryos2026 for controlled comparisons along the problem chain, Blauth2024 for realism at scale under an industrial cost objective.

Two pieces of my PhD work are now public and worth introducing together: Kayros, an open-source solver, and Poryos2026, a benchmark family it produces solutions for. Their names are a matched pair, borrowed from Greek: Kairos for the right moment (timing), Poros for the way or path. Kayros is about timing, Poryos is about the ways.

Kayros

Kayros is an open-source solver for duration-minimization time-dependent vehicle routing, covering both the time-window variant (TDVRPTW) and the plain TDVRP. Time-dependent means travel times change with the time of day, so the same trip can take more or less time depending on when you set out. Kayros represents this with continuous piecewise-linear arrival-time functions rather than a coarse time discretization.

To my knowledge it is the first solver that is both anytime and exact and open source for this duration-minimization time-dependent setting with a rich piecewise-linear time-dependent representation. It runs in two modes on one engine: an anytime heuristic that returns steadily improving solutions under any time budget, and an exact branch-price-and-cut mode that can certify optimality. The exact side runs on the open-source HiGHS solver, so no commercial license is required.

At the time of this announcement, Kayros was in beta at version 1.1.3. It is developed as part of my PhD and installable from PyPI:

pip install kayros

The source is on GitHub (MIT, Python 3.11+). The technical report described in the update above was forthcoming when this post was written.

Poryos2026

Poryos2026 is a new benchmark family generated to stress-test time-dependent routing on real city road networks with controlled synthetic congestion. Its road geometry comes from OpenStreetMap across five cities: Lyon, Paris, San Francisco, Hong Kong, and Tokyo. Instances come in six sizes, from 10 up to 1000 customers, under several traffic models and intensities.

The headline set is 360 time-dependent TDVRPTW instances (720 if you also count the TDVRP view), plus static CVRP and VRPTW projections on top that are directly comparable to the time-dependent ones since they share the same underlying network and customer locations. Each instance ships with a best-known Duration solution, seeded by Kayros anytime campaigns run on the Grid’5000 cluster. The benchmark data is released under ODbL 1.0, in keeping with its OpenStreetMap origin.

Poryos2026 lives in the MAMUT-routing catalog and is exposed programmatically through the mamut-routing-lib library:

pip install mamut-routing-lib

The family is available there as BenchmarkName.PORYOS_2026. You can browse the instances, their metadata, and their best-known solutions on the family page: mamut-routing.onyr.net/benchmarks/tdvrptw/poryos2026.

How they fit together

Kayros is the engine, and Poryos2026 is one of the datasets it was benchmarked on. The family combines real road geometry with reproducible, modeled traffic, so comparisons can vary time dependence while keeping the underlying customer locations fixed. The solver produces and refines the best-known solutions catalogued for the family. For more on the catalog itself, see my companion post on the MAMUT-routing mirror.

What MAMUT-routing is

MAMUT-routing is the public benchmark and instance catalog of the ANR-MAMUT project (Machine learning And Matheuristics algorithms for Urban Transportation, grant ANR-22-CE22-0016), run at Université Bretagne Sud (Lab-STICC). It catalogs vehicle-routing instances, from the classic VRPTW and CVRP families to modern time-dependent TDVRPTW and TDVRP families, each shipped in a documented JSON format with per-instance best-known solutions and a clearly stated objective contract. The benchmark catalog is developed by Adrien Pichon and mylself under the supervision of Romain Billot, Lina Fahed, Alexandru-Liviu Olteanu, Marc Sevaux and Christine Solnon within the ANR-MAMUT project, and I am glad to help make their work more visible in this AI-driven fast-paced field of vehicle routing optimization.

What the mirror serves

The mirror is a faithful, static copy of the upstream site:

• the catalog and family pages,
• the raw benchmark artifacts (instances and their best-known solutions),
• the per-city route geometries derived from OpenStreetMap extracts.

As a small taste of the catalog, here is the Poryos2026 time-dependent family, a set of instances whose congestion comes from real city road networks. I write more about it in a companion post on the Kayros solver.

Why a personal mirror

This is my own independent mirror, not a fork, though it might evolve in the future to include additional features or elements that matter to my PhD research. As of now, every page carries a disclosure banner making that clear and linking back to the source. The official site, mamut-routing.univ-ubs.fr, is temporarily unavailable, so this mirror is a convenient stand-in in the meantime. When the official site is back, it remains the canonical reference.

Gurobi on NixOs

This guide presents both manual and automated installation and usage of Gurobi on NixOs for C++ development. You can head directly to the automated section, and use the manual one for further reference. I recommend the official tutorial on Gurobi on C++ for a smooth introduction to using the Gurobi API with C++.

Manual install and setup on NixOs

1. First, head towards the Gurobi official website. There, create an account, and get the appropriate licence. In my case, I’m an academic and I went for the Free Academic Named-User Licence.

2. Go to the official download page and download the Gurobi archive and checksum. For instance, I downloaded gurobi11.0.3_linux64.tar.gz and gurobi11.0.3_linux64.tar.gz.md5 .

3. Check the archive with the checksum. Run md5sum yourfile.tar.gz and md5sum -c yourfile.md5. I got:

 ❮onyr ★ nixos❯ ❮Downloads❯❯ md5sum gurobi11.0.3_linux64.tar.gz 
cec6b3eeb3725ce47e492a31b54ea0dd  gurobi11.0.3_linux64.tar.gz
 ❮onyr ★ nixos❯ ❮Downloads❯❯ md5sum -c gurobi11.0.3_linux64.tar.gz.md5 
gurobi11.0.3_linux64.tar.gz: OK

1. Extract the archive: tar -xzvf gurobi11.0.3_linux64.tar.gz.

2. Move the extracted directory where you like. For me, it’s inside my /home/onyr partition: mv gurobi1103 /home/onyr/

According to the tutorial: “A C++ program that uses Gurobi must link in both the Gurobi C++ library libgurobi_c++.a and the Gurobi C library libgurobi100.so.”

1. Now it’s time to build libgurobi_c++.a compatible with NixOs C++ version. Go to gurobi1103/linux64/src/build, create a temporal nix-shell environment with C++ packages: nix-shell -p gcc gnumake gdb valgrind. Now you can build the file by running make:

 ❮onyr ★ nixos❯ ❮build❯❯ nix-shell -p gcc gnumake gdb valgrind
these 7 paths will be fetched (13.68 MiB download, 85.82 MiB unpacked):
  /nix/store/3w65f90aqzb03ldsyjdp4hbxvgbcqz5l-gdb-15.1
  /nix/store/3ssglpx5xilkrmkhyl4bg0501wshmsgv-gnumake-4.4.1
  /nix/store/w966rfxjjc153qn6ifb2v3slwz80364g-libipt-2.1.1
  /nix/store/y5r964x88p1k989lpmi79m9jxvlr479m-setup-debug-info-dirs-hook
  /nix/store/k2q837a8gn180n4zs6pw3ac2hcabqlkb-source-highlight-3.1.9
  /nix/store/qy8niksnmmfd1zim8kdw020l53agbagd-valgrind-3.23.0
  /nix/store/vmkz2plcbvmikjxlpjklh77w5ygy4aw3-valgrind-3.23.0-dev
copying path '/nix/store/w966rfxjjc153qn6ifb2v3slwz80364g-libipt-2.1.1' from 'https://cache.nixos.org'...
copying path '/nix/store/3ssglpx5xilkrmkhyl4bg0501wshmsgv-gnumake-4.4.1' from 'https://cache.nixos.org'...
copying path '/nix/store/k2q837a8gn180n4zs6pw3ac2hcabqlkb-source-highlight-3.1.9' from 'https://cache.nixos.org'...
copying path '/nix/store/y5r964x88p1k989lpmi79m9jxvlr479m-setup-debug-info-dirs-hook' from 'https://cache.nixos.org'...
copying path '/nix/store/qy8niksnmmfd1zim8kdw020l53agbagd-valgrind-3.23.0' from 'https://cache.nixos.org'...
copying path '/nix/store/3w65f90aqzb03ldsyjdp4hbxvgbcqz5l-gdb-15.1' from 'https://cache.nixos.org'...
copying path '/nix/store/vmkz2plcbvmikjxlpjklh77w5ygy4aw3-valgrind-3.23.0-dev' from 'https://cache.nixos.org'...

[nix-shell:~/gurobi1103/linux64/src/build]$ make
g++ -m64 -fPIC -O -I../../include -c ../cpp/Env.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/Model.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/attrprivate.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/Var.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/Constr.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/LinExpr.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/QuadExpr.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/Exception.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/Callback.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/Column.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/SOS.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/QConstr.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/GenConstr.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/TempConstr.cpp
g++ -m64 -fPIC -O -I../../include -c ../cpp/Batch.cpp
ar rv libgurobi_c++.a Env.o Model.o attrprivate.o Var.o Constr.o LinExpr.o QuadExpr.o Exception.o Callback.o Column.o SOS.o QConstr.o GenConstr.o TempConstr.o Batch.o
ar: creating libgurobi_c++.a
a - Env.o
a - Model.o
a - attrprivate.o
a - Var.o
a - Constr.o
a - LinExpr.o
a - QuadExpr.o
a - Exception.o
a - Callback.o
a - Column.o
a - SOS.o
a - QConstr.o
a - GenConstr.o
a - TempConstr.o
a - Batch.o

1. The file libgurobi_c++.a has been created, so copy or move it to lib like so: cp libgurobi_c++.a ../../lib/

2. Now you should be able to compile your C++ project. As an example, go to gurobi1103/linux64/examples/build and run make to build the example. You might run into an error: libgurobi110.so: cannot open shared object file: No such file or directory. This is due to the dynamic linker not being able to find the libgurobi110.so library when you run the compiled executable. This can happen if the library isn’t in a directory that’s part of the standard library search paths. To fix that when running the executable, you need to add the directory containing libgurobi110.so to the LD_LIBRARY_PATH environment variable, so the dynamic linker can find it. Run export LD_LIBRARY_PATH=~/gurobi1103/linux64/lib:$LD_LIBRARY_PATH to temporarily add. In your NixOs project, use a shell hook in your flake.nix to automatically add it (we see that later).

[nix-shell:~/gurobi1103/linux64/examples/build]$ make mip1_c++
g++ -std=c++98 -m64 -g -o mip1_c++ ../c++/mip1_c++.cpp -I../../include/ -L../../lib -lgurobi_c++ -lgurobi110 -lm

[nix-shell:~/gurobi1103/linux64/examples/build]$ ./mip1_c++ 
./mip1_c++: error while loading shared libraries: libgurobi110.so: cannot open shared object file: No such file or directory

[nix-shell:~/gurobi1103/linux64/lib]$ export LD_LIBRARY_PATH=~/gurobi1103/linux64/lib:$LD_LIBRARY_PATH

[nix-shell:~/gurobi1103/linux64/lib]$ echo $LD_LIBRARY_PATH
/home/onyr/gurobi1103/linux64/lib:/usr/local/cuda/lib64:/usr/local/cuda/lib64:/nix/store/29m4aiz014s7wv0jfi7ky2p8wypbi7iw-pipewire-1.2.1-jack/lib

[nix-shell:~/gurobi1103/linux64/examples/build]$ ./mip1_c++ 
Set parameter LogFile to value "mip1.log"
Error code = 10009
No Gurobi license found (user onyr, host nixos, hostid 3163950c, cores 20)

1. As you can see in the logs, we are missing the licence file. Go to the Gurobi User Portal and get the appropriate licence key <YOUR-LICENCE>. Now we need the grbgetkey command line tool to generate the licence file gurobi.lic. To do so, run the grbgetkey executable located in gurobi1103/linux64/bin.

[nix-shell:~/gurobi1103/linux64/bin]$ grbgetkey 
info  : grbgetkey version 11.0.3, build v11.0.3rc0
info  : Platform is linux64 (linux) - "NixOS 24.11 (Vicuna)"

Please enter the Key Code for the license
(format is xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx):

[nix-shell:~/gurobi1103]$ grbgetkey <YOUR-LICENCE>
info  : grbgetkey version 11.0.3, build v11.0.3rc0
info  : Platform is linux64 (linux) - "NixOS 24.11 (Vicuna)"
info  : Contacting Gurobi license server...
info  : License file for license ID ***** was successfully retrieved
info  : License expires *****
info  : Saving license file...

In which directory would you like to store the Gurobi license file?
[hit Enter to store it in /home/onyr]:   	

info  : License ***** written to file /home/onyr/gurobi.lic

1. Now, the example file should works:

[nix-shell:~/gurobi1103/linux64/examples/build]$ ./mip1_c++ 
Set parameter Username
Set parameter LogFile to value "mip1.log"
Academic license - for non-commercial use only - expires 2025-08-30
Gurobi Optimizer version 11.0.3 build v11.0.3rc0 (linux64 - "NixOS 24.11 (Vicuna)")

CPU model: 12th Gen Intel(R) Core(TM) i7-12700H, instruction set [SSE2|AVX|AVX2]
Thread count: 20 physical cores, 20 logical processors, using up to 20 threads

Optimize a model with 2 rows, 3 columns and 5 nonzeros
Model fingerprint: 0x98886187
Variable types: 0 continuous, 3 integer (3 binary)
Coefficient statistics:
  Matrix range     [1e+00, 3e+00]
  Objective range  [1e+00, 2e+00]
  Bounds range     [1e+00, 1e+00]
  RHS range        [1e+00, 4e+00]
Found heuristic solution: objective 2.0000000
Presolve removed 2 rows and 3 columns
Presolve time: 0.00s
Presolve: All rows and columns removed

Explored 0 nodes (0 simplex iterations) in 0.00 seconds (0.00 work units)
Thread count was 1 (of 20 available processors)

Solution count 2: 3 2 

Optimal solution found (tolerance 1.00e-04)
Best objective 3.000000000000e+00, best bound 3.000000000000e+00, gap 0.0000%
x 1
y 0
z 1
Obj: 3

Automatic install and setup.

If you have any problem, refer to the manual installation. Many errors can be understood this way. Hence the presence of the manual part in this guide.

1. Same as before, create a Gurobi account, and get a licence.

2. Since we are on NixOs, let’s use the community wrapper for Gurobi, well-named gurobi (See on NixOs package search). In our project, we are going to rely on a flake.nix file to handle dependencies. Create a new project directory, and add at the root of this directory the following flake.nix file

{
  description = "C++ development environment with Gurobi";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
    flake-utils.url = github:numtide/flake-utils;
  };

  outputs = { self, nixpkgs, flake-utils, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
      in
      {
        devShells.default = pkgs.mkShell {
          packages = [
            # C/C++ development
            pkgs.gcc
            pkgs.gnumake
            pkgs.gdb
            pkgs.valgrind

            pkgs.gurobi # Gurobi solver. Requires a license. Add it using command `grbgetkey <YOUR_LICENSE_KEY>`
          ];

          shellHook = ''
            export LD_LIBRARY_PATH=${pkgs.gurobi}/lib:$LD_LIBRARY_PATH
            export GUROBI_HOME=${pkgs.gurobi}
            export GUROBI_VERSION=$(basename $(ls -d ${pkgs.gurobi}) | sed 's/.*-\([0-9]\+\)\.\([0-9]\+\).*/\1\2/')
            echo "Welcome to your C++ development environment with Gurobi"
          '';
        };
      }
    );
}

This file download into you nix store the necessary dependencies. Since the package gurobi has a unfree licence, you might need to enter the dev environment with a trick, by using the following command: export NIXPKGS_ALLOW_UNFREE=1 & nix develop --impure.

1. You still need to add a licence with this method. In the dev environment, run grbgetkey <YOUR-LICENCE> using the licence key you got from Gurobi User Portal.

2. Done. Once the licence is added, you can build and run the classical provided example: mip1_c++.cpp, by using the following Makefile (make sure to remplace spaces with tabs):

COMPILER = g++
ARCHITECTURE_FLAGS = -march=native

# Set GUROBI_HOME to the path of your Gurobi installation, automatically done in flake.nix
# Set GUROBI_VERSION to the version of your Gurobi installation, automatically done in flake.nix

GUROBI_FLAGS = -I $(GUROBI_HOME)/include -L $(GUROBI_HOME)/lib -lgurobi_c++ -lgurobi$(GUROBI_VERSION) -lm
COMPILER_FLAGS = -std=c++17 -m64 -Wall -Wfatal-errors -O3 $(ARCHITECTURE_FLAGS)

all: main

main: mip1_c++.cpp
    $(COMPILER) $(COMPILER_FLAGS) -o main mip1_c++.cpp $(GUROBI_FLAGS)

clean:
    rm -f main

This should give you:

 ❮onyr ★ nixos❯ ❮gurobi❯❯ export NIXPKGS_ALLOW_UNFREE=1; nix develop --impure
warning: Git tree '/home/onyr/code/phd/gurobi' is dirty
Welcome to your C++ development environment with Gurobi
 ❮onyr ★ nixos❯ ❮gurobi❯❯ cd examples/mip1/
 ❮onyr ★ nixos❯ ❮mip1❯❯ make clean 
rm -f main
 ❮onyr ★ nixos❯ ❮mip1❯❯ make
g++ -std=c++17 -m64 -Wall -Wfatal-errors -O3 -march=native -o main mip1_c++.cpp -I /nix/store/rfs8s03jv4srizn088igkll8yxmyc0mq-gurobi-11.0.3/include -L /nix/store/rfs8s03jv4srizn088igkll8yxmyc0mq-gurobi-11.0.3/lib -lgurobi_c++ -lgurobi110 -lm
 ❮onyr ★ nixos❯ ❮mip1❯❯ ./main 
Set parameter Username
Set parameter LogFile to value "mip1.log"
Academic license - for non-commercial use only - expires 2025-08-30
Gurobi Optimizer version 11.0.3 build v11.0.3rc0 (linux64 - "NixOS 24.11 (Vicuna)")

CPU model: 12th Gen Intel(R) Core(TM) i7-12700H, instruction set [SSE2|AVX|AVX2]
Thread count: 20 physical cores, 20 logical processors, using up to 20 threads

Optimize a model with 2 rows, 3 columns and 5 nonzeros
Model fingerprint: 0x98886187
Variable types: 0 continuous, 3 integer (3 binary)
Coefficient statistics:
  Matrix range     [1e+00, 3e+00]
  Objective range  [1e+00, 2e+00]
  Bounds range     [1e+00, 1e+00]
  RHS range        [1e+00, 4e+00]
Found heuristic solution: objective 2.0000000
Presolve removed 2 rows and 3 columns
Presolve time: 0.00s
Presolve: All rows and columns removed

Explored 0 nodes (0 simplex iterations) in 0.00 seconds (0.00 work units)
Thread count was 1 (of 20 available processors)

Solution count 2: 3 2 

Optimal solution found (tolerance 1.00e-04)
Best objective 3.000000000000e+00, best bound 3.000000000000e+00, gap 0.0000%
x 1
y 0
z 1
Obj: 3

That’s how to get Gurobi to Work on NixOs.

Closing note

This is the kind of setup that feels fiddly once and then never again. That is, in the end, the promise of the declarative approach.

Il avait vécu tant d’aventures. Versé tant de larmes, et goûté tant de joies. Il était parti il y a longtemps. Il avait renoncé à cette vie rangée et monotone qu’on les enfants bien nés dans les bourgs et les citadelles. Il avait choisi cette vie d’itinérance et d’aventure à parcourir les étendues célestes où l’on ignore au matin où la destinée nous emporte au soir. Il était déjà presque trop tard pour monter un camps. Mais il était bien. Il voulait profiter encore de la solitude heureuse des voyageurs solitaires, sa main gantée sur le pommeau de son épée et les replis de sa cape flottant dans le vent du soir.

Selfies from my pilgrimage #Lyon2Lourdes, the first part of my journey to Saint-James of Compostela, in the middle of winter 2023.

On March 14, 2023, after 25 days of travel on the paths of Saint-James from the Fourvière basilica overlooking the city of Lyon, I finally reached Lourdes! What joy and what a welcome!

This day remains etched in my memory. I thank Jean-Louis Doux for his kindness, his advice, and his prayers.

Today, nearly a year and a half later, this memory is still vivid. From now on, on some virtual paths of the Web, is a small beacon towards this resting place for travelers: La Ruche Lourdes website.

Any good project needs to start somewhere, and a Hello World! is for sure a rightful way to do so. So here we are indeed.

Who knows where it will go from now.

It is now time to unleash the new baby website of my programming association: insalgo.fr

This project is based on Jekyll, a popular tool to generate static website, easy to learn and maintain, well integrated into GitHub in which members are already familiar, and extensively documented and adopted. It was thus the perfect tool for the job.

It took me around 5h to install and parameter Jekyll on my NixOs-powered laptop. After around 1 year on this amazing distro, I tend to be pretty effective when having to deal with software install. However, getting Jekyll to work on my dev environment was less easy that the widespreadness of this tool was hinting to me.

Making Jekyll work on NixOs

First, I discovered not a single flake.nix file on the whole GitHub with Jekyll properly configured with a theme like Minima, since I was trying to follow the tutorial. So I had to make my own. Second, installing the package minima into buildInputs was not making this package discoverable for the bundler of rubyPackages.jekyll.

Following the tutorial for using Jekyll on the official website, I did:

1. Install prerequisites: Ruby, and Jekyll, from the nixpkgs store into my flake.nix of the project.
2. Install Jekyll and Bundler gem: gem install jekyll bundler
3. Create a new Jekyll site using jekyll new INSAlgo

What I realized is that the bundler is actually breaking NixOs contained environments, by downloading its packages as gems directly instead of relying on NixOs internal packages. Since NixOs doesn’t follow Linux standard paths due to that containment, some paths are incorrectly setup and I kept having the following error, despite the package minima being properly installed on both NixOs internal store and ruby’s local one too.

A quick fix I did was finding this package, and adding a shellHook to my flake to manually hard-code the path, taking into account potential new versions. Yes, it’s clearly dirty, and not 100% reproducible. Yes, there is probably a better way to do so, but I already spent 2h on that problem and my goal was to make a website quickly, not spend all my time writing a perfect flake.

If you ever make a better flake.nix for Jekyll, I kindly invite you to do a PR on this repo with the updated flake.

So here is the flake that made my Jekyll project works flawlessly:

{
  description = "Jekyll website template";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
        minima = pkgs.rubyPackages.minima;
        minimaVersion = builtins.getAttr "version" minima;
        minimaPath = "${minima}/lib/ruby/gems/3.1.0/gems/minima-${minimaVersion}/_sass";
      in
      {
        formatter = pkgs.nixpkgs-fmt;

        # development environment
        devShells.default = pkgs.mkShell {
          buildInputs = [
            pkgs.ruby
            pkgs.rubyPackages.jekyll
            pkgs.rubyPackages.jekyll-sitemap
            minima
          ];

          shellHook = ''
            if [ ! -d "${minimaPath}" ]; then
              echo "Error: The SASS_PATH (${minimaPath}) does not exist."
              exit 1
            else
              export SASS_PATH=${minimaPath}
            fi
          '';
        };

        packages.default = pkgs.stdenv.mkDerivation {
          name = "jekyll-insalgo-website";
          src = ./.;
          buildInputs = [
            pkgs.ruby
            pkgs.jekyll
            pkgs.rubyPackages.jekyll-sitemap
          ];
          buildPhase = ''
            jekyll build
          '';
          installPhase = ''
            cp -r _site $out
          '';
        };
      }
    );
}

The exact problem here is that an environment variable for the theme is missing. Make sure to install the theme as a package, and set SASS_PATH accordingly, and adapt your minimaPath path to your own environment.

Informatiquement vôtre,