3 ms·
I don't agree multiple processes are hackish at all. CPUs/MMUs have dedicated hardware for managing memory, O/Ss have tools to limit and monitor memory usage, a
by tannhaeuser 8y ago
I don't agree multiple processes are hackish at all. CPUs/MMUs have dedicated hardware for managing memory, O/Ss have tools to limit and monitor memory usage, and separate memory regions/segments can be very effective and simple means for security isolation (save for meltdown/rowhammer-style attacks). I know this could be used as a general argument against any innovation, but single-process-per-requests have worked well since inetd (4.3BSD in 1977). Considering hardware has improved orders-of-magnitudes since, what is the advantage of doing the same with very restricted programming models, especially when developer costs are dominating new service developments?
- fwsgonzo 8y agoYou present good points, but with IncludeOS you can simply liveupdate it to itself in a few milliseconds to get a pristine heap, and perhaps a few fixes as well. Won't count as downtime.
- perbu 8y agoI'm not saying multiple processes are a hack, just relying on fork/exec to clean up memory. Safeguarding against memory fragmentation is imho a solved problem - or at least solvable if you apply known methods. Other than that I think you are right. Unless IncludeOS can prove that it can offer something akin to the same level of convenience as current Linux-based systems have I think it'll be hard for the OS to get traction. The upside would be stronger isolation and a system that would be a lot harder to break into. The absence of system calls makes most attacks very, very inconvenient and the absence of self-modification functionality is strengthening it further.