271–275 of 275 posts
Something that I recently have explored is the optimization of Docker layers and startup time for large containers. Using shared storage, tar layers preload, overlayBD https://github.com/codeexec/overlaybd-deploy is something that I would like to see more natively. Great article
This is neat. I’m about to dive into snapshooters myself, any pitfalls to watch out for?
Earlier quoted context omitted.
That's a fair point, and shelling out to id is probably a good solution. I guess what bothers me is the software authors who don't think this through, leaving applications non-functional in these situations. At least with Go, if you do CGO_ENABLED=0 , and you use the stdlib functions to resolve user information, you end up with parsed /etc/passwd instead of shelling out to id . The Go stdlib should maybe shell out to…
On the other hand, the NSS modules are broken beyond fixing. So promoting ecosystems that don't use them might finally spur the development of alternatives.
Moving from linking stuff in-process to IPC (such as systemd-userdbd is promoting) _seems_ to me like a natural thing to do, given the nastiness that can happen when you bring something complex into your own address space (via C semantics nonetheless). But I'm not very knowledgeable here and would be interested to hear your overall take.
Earlier quoted context omitted.
It obviously means you dont use a scripting language, instead use a real langauge with a compiler.
Calling "go" a "real language" is stretching the definition quite a bit. Real languages don't let errors go silently unnoticed.
Earlier quoted context omitted.
On the other hand, the NSS modules are broken beyond fixing. So promoting ecosystems that don't use them might finally spur the development of alternatives.
Could be interesting. What do you see as the main problems with NSS? I've never needed to use it directly myself. It seems quite crusty of course, but presumably there's more that your referencing. Moving from linking stuff in-process to IPC (such as systemd-userdbd is promoting) _seems_ to me like a natural thing to do, given the nastiness that can happen when you bring something complex into your own address space…
For example, you technically can't sandbox any app with NSS/PAM modules, because a module might want to send an email (yes, I saw that in real life) or use a USB device.
NSS/PAM need to be replaced with IPC-based solutions. systemd is evolving a replacement for PAM.
And for NSS modules in particular, we even have a standard solution: NSCD. It's even supported by musl libc, but for some reason nobody even _knows_ that it exists. Porting the NSCD protocol to Go is like 20 minutes of work. I looked at doing that more than once, but got discouraged by the other 99% of complexity in getting something like this into the core Go code.
installing docker desktop on my personal laptop permanently bricked it, right in the middle of chip/memory shortage. thanks docker!!!