| 19 Jul 2025 |
 emily | from-scratch source builds for entire Java dep trees would be cool and there is stuff in Gradle that could make that work, but it's not where the ecosystem is by default | 20:10:30 |
 vog | Ok, no problem for me, actually this simplifies my packaging work. ;-) | 20:11:21 |
 msgilligan | I would like to see bootstrappable Java libraries/jars someday, but emily is right, it's not currently practical. | 20:11:58 |
| msgilligan | I don't know, but I took a quick look at the Keycloak website and it is recommending (requiring?) JDK 21, so you shouldn't have to use a 3rd-party (possibly native) library for the raw socket access. I don't know whether the JDBCs drivers are using JEP 380 yet. | 20:14:11 |
| msgilligan | * I don't know, but I took a quick look at the Keycloak website and it is recommending (requiring?) JDK 21, so you shouldn't have to use a 3rd-party (possibly native) library for the raw socket access. I don't know whether the JDBC drivers are using JEP 380 yet. | 20:15:14 |
| vog | Well, the PostgreSQL JDBC driver explicitly recommends using junixsocket: https://jdbc.postgresql.org/documentation/use/#unix-sockets | 20:15:41 |
| vog | (and doesn't mention JEP 380 at all) | 20:15:56 |
| vog | This article explains everything quite in detail: https://www.morling.dev/blog/talking-to-postgres-through-java-16-unix-domain-socket-channels/ | 20:22:16 |
| msgilligan | I'm currently reading it... | 20:22:37 |
| vog | Summary:
- With postgresql_jdbc we are out of luck with JEP 380, we do need junixsocket
| 20:22:44 |
| vog |
- The Vert.x Postgres Client does support JEP 380, and might even be accessible by keycloak given that keycloak uses Quarkus. But I have no idea how to configure this.
| 20:23:45 |
| vog | (at least that's my understand of this issue. Feel free to correct me.) | 20:25:02 |
| msgilligan | Are you going to use the Keycloak module: https://nixos.org/manual/nixos/stable/index.html#module-services-keycloak ? | 20:27:24 |
| vog | No, because I need it to run in a bwrap sandbox, in which running systemd is a pain. So I essentially just use pkgs.keycloak.override { ... my config, my plugins ... } and this serves my needs pretty well. | 20:33:03 |
| vog | (except for the missing unix socket support) | 20:33:20 |
| emily | systemd can all the bwrap sandboxing stuff itself | 20:33:26 |
| emily | many service modules in NixOS already apply a bunch of such hardening | 20:33:33 |
| emily | * systemd can do all the bwrap sandboxing stuff itself | 20:33:40 |
| vog | It's not just about hardening. It's about providing lightweight containers. | 20:34:02 |
| vog | So I need process supervision inside the sandbox, not outside. | 20:34:43 |
| emily | right, NixOS modules are quite bad about being unnecessarily singleton | 20:35:00 |
| vog | The s6 tool do perform this job perfectly. | 20:35:03 |
| emily | we do have NixOS containers for that, but they are moderately heavyweight | 20:35:18 |
 Infinidoge 🏳️⚧️ | In reply to @emilazy:matrix.org
right, NixOS modules are quite bad about being unnecessarily singleton Entire reason behind nix-minecraft lmao | 20:35:30 |
| Infinidoge 🏳️⚧️ | Being able to host Exactly One minecraft server sucks | 20:35:54 |
| vog | Ok, but back to you original quesion: No, I don't neet a module configuration, just a pkgs configuration. But why were you asking? | 20:36:28 |
| emily | unfortunately the module system is kind of bad (my hot take) | 20:36:33 |
| emily | (but the things we do with the module system are nice) | 20:36:47 |
| emily | do wish we had something that didn't make singletons the happy path | 20:37:02 |
| emily | because manual containerization sucks | 20:37:10 |
