.... i can understand being like .... proactive. But maybe the failable allocations thing leading to writing your own allocator is premature? idk ...
it's one of the core parts of the security model....
i would hope because there's such strict controls in rust for memory management that you wouldn't have the possibility for allocation fails to begin with? idk ?
if it's a low memory situation, i think there's other ways to handle this ... but i can understand not wanting anything to change other than the language.
.... i can understand being like .... proactive. But maybe the failable allocations thing leading to writing your own allocator is premature? idk ...
it's one of the core parts of the security model....
i would hope because there's such strict controls in rust for memory management that you wouldn't have the possibility for allocation fails to begin with? idk ?
if it's a low memory situation, i think there's other ways to handle this ... but i can understand not wanting anything to change other than the language.
but maybe it's something that gets better?
Then Rust could not be any part of the init executable. A failed allocation would be a kernel panic.
> Static linking for a project like systemd that is split into many tiny components (> 180 binaries currently) is simply not practical or desirable.
It's pretty easy to do this though isn't it? Just have a single binary and switch on argv[0]. Busybox has been doing that for literally decades.
[flagged]