| 13 Apr 2026 |
Lisanna | decimal versioning spotted | 16:28:52 |
Taeru | In reply to @lisanna-dettwyler:matrix.org decimal versioning spotted Semvar is a lie made up by small numbers to keep you from using bigger numbers. | 16:35:08 |
John Ericson | Well for an AFNix channel | 19:22:07 |
John Ericson | France can do better than GendBuntu! | 19:23:08 |
| 14 Apr 2026 |
aloisw | I fail to see how "we want to move to Linux because nationalism" is on-topic for AFNix either. | 04:10:58 |
Linux Hackerman | raitobezarius I think you can abandon https://gerrit.lix.systems/c/lix/+/5081 | 07:26:46 |
piegames | In reply to @Ericson2314:matrix.org Well for an AFNix channel This is the Lix development channel, where people involved with the Lix codebase can discuss their operations and issues. Please put more consideration into your communication | 10:28:22 |
raitobezarius | done, tysm for investigating | 10:32:44 |
| Rutile joined the room. | 21:20:41 |
| legacy_rootile -> @rootile:flausch.social changed their display name from Rutile (rootile) to legacy_rootile -> @rootile:flausch.social. | 21:42:36 |
| 15 Apr 2026 |
ShalokShalom | In case someone is interested into arguments why semantic versioning is broken in itself, listen to Rich Hickey. | 13:15:02 |
ShalokShalom | * In case someone is interested into arguments why semantic versioning is broken in itself, listen to Rich Hickey. | 13:15:14 |
piegames | Off-topic, please | 13:20:12 |
Sergei Zimmerman (xokdvium) | Is Lix going to go with a zygote fork helper? | 18:15:09 |
Sergei Zimmerman (xokdvium) | To mitigate the slow fork times? | 18:15:48 |
raitobezarius | well, lix has already very fast fork times now | 18:16:45 |
raitobezarius | but vfork is dangerous | 18:16:49 |
raitobezarius | so if we can have the speed and the safeness (aka zygote fork helper), that'd be great | 18:17:02 |
raitobezarius | but lower priority | 18:17:05 |
Sergei Zimmerman (xokdvium) | How did you achieve that? It's using the plan old fork() if I read the code correctly and that's still slow when there is a lot of memory allocated | 18:19:58 |
raitobezarius | vfork | 18:20:51 |
raitobezarius | grep inVFork | 18:21:03 |
raitobezarius | in the codebase | 18:21:04 |
raitobezarius | /**
* runs a callback in a vforked child process that shares its address space with
* the current process. the child behaves much like a thread as a result and the
* callback must not make changes to process memory that we cannot undo from the
* parent, otherwise we may leak memory or fully trash the parent address space.
*
* NOTE: see `asVFork` for safety information regarding credentials and signals.
*
* throws an exception if the child exec's or otherwise doesn't return a result.
*/
static auto inVFork(int flags, auto fn)
{
auto [pid, result] = asVFork(flags, fn);
if (result) {
return std::move(result->value());
} else {
throw Error("vfork child unexpectedly did not produce a value");
}
}
this is the entrypoint of the magic
| 18:21:26 |
raitobezarius | some plain old fork() might be used in other places | 18:21:43 |
Sergei Zimmerman (xokdvium) | Ah that's for the sandboxing setup, I see. I was looking at libexec helpers | 18:21:50 |
raitobezarius | but wrt to derivation builds, the overhead is around 2µs ? | 18:21:59 |
raitobezarius | getting lower would be nice ofc | 18:22:44 |
raitobezarius | but not urgent | 18:22:49 |
raitobezarius | it is now possible to build 1M derivations reasonably | 18:23:00 |