<isd>
Many things would be easier if Sandstorm could prescribe the running kernel & installed filesystem(s).
<isd>
If we could mandate newer kernels I'd be tempted to go yak shaving and make inotify work better, but that wouldn't do us any good unless we wanted to either (a) maintain support for two implementations or (b) drop support for any kernel that doesn't support the new thing that was just added.
<ocdtrekkie>
It is indeed a largely self-solving problem with enough time, but I suppose at minimum we could document the solution for people?
<ocdtrekkie>
How to check the setting and how to raise it.
<isd>
Yeah. Maybe for extra credit, add a thing to the startup logic that checks for this (and possiblly other kernel configurations that would likely be problematic).
<ocdtrekkie>
I believe you had dream future plans of handling storage more like Blackrock did, so fixing this may not be worth too much effort if users can fix it themselves.
<isd>
This is news to me?
<isd>
Not sure what plans you're referring to.
<ocdtrekkie>
Maybe I misrememeber.
<isd>
But yeah, I think documenting this and the workaround is good for now.
<isd>
I was talking about putting app storage in a squashfs, but thats for packages, not mutable grain storage.
<isd>
Maybe that's what you remembered?
<ocdtrekkie>
I will say the wildcard misconfiguration detection warning works really well at routing people to support paths.
<ocdtrekkie>
That is probably it.
<isd>
I am several yaks deep in making that happnen, incidentally.
<ocdtrekkie>
Something similarly very visible in the admin panel about the issue could direct people directly to the relevant doc page too.
<isd>
Yeah, not a bad idea.
<isd>
Separately, we should also actually have a conversation about what kernels to support. I do not like the idea of keeping the current version forever, which is whatever RHEL was running when privileged sandbox mode was first implemented I think?
<isd>
I'd like to have a defined policy that lets us eventually use new kernel features. Ideally we'd have an incentive to actually make the kernel better where possible.
<isd>
But even without us actually fixing things in the kernel ourselves, we'll be stuck with flaky APIs like inotify even if somebody else does better at some point...
<isd>
I don't want to get trigger happy with dropping support for stuff people actually use. But I'm inclined to suggest that supportting whatever version is in debian oldstable and the oldest supported ubuntu LTS is as conservative as we should get.
<isd>
RHEL's "full support" period is also nominally 5 years. We should definitely not be trying to outdo them.
<ocdtrekkie>
The issue is "we don't know what people actually use".
<isd>
Sure. But I think if they're using something that's not on a distro getting security updates from RedHat, Canonical, or Debian, we really should tell them they're on their own...
<isd>
...or at least demand to be paid.
<ocdtrekkie>
I think it'd be absolutely fair to have a minimum supported bar. We might not explicitly try to break things outside that, and could still accept non-extreme fixes contributed by others to support older releases.
<ocdtrekkie>
Part of the problem is for the target casual Sandstorm user... like, if it works people will tend to fire and forget it.
<isd>
Agree. But e.g. it might be nice to be able to assume the kernel is post cgroups-v2...
<ocdtrekkie>
Not an issue if our Sandstorm server is a self-managing distro but probably an issue at present.
<ocdtrekkie>
Like... I wonder what Alpha presently runs on.
<isd>
At some point I want to provide a sandstorm distro, but there we'll be able to just upgrade the kernel ourselves if we want newer features. So this really only concerns people who managed to set up Linux themselves.
<ocdtrekkie>
I think it'd be reasonable though to set a rolling support bar though.
<ocdtrekkie>
Might also be a good use of the misconfiguration warning though: If we intend to break someone's stuff in the near future we could detect it and notify them.
<ocdtrekkie>
In a non-telemetry-based model, we should have Sandstorm proactively notify administrators if their software is going to break.