blog

commit: 2c83d946e4be48f392df4b1418b66d7cee61ae38
parent 6bab97a7671a999cd46104645090ac5265d93381
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date:   Tue,  9 May 2023 01:10:04 +0200

notes/unix-defects: ulimit

Diffstat:
M
notes/unix-defects.xhtml
6
++++++

1 file changed, 6 insertions(+), 0 deletions(-)
diff --git a/notes/unix-defects.xhtml b/notes/unix-defects.xhtml
@@ -88,6 +88,12 @@
 				<code>/dev</code> should be a virtual filesystem, say something that points to a device manager like udev or the kernel itself. Similarly to how it's done for <code>/proc</code> and <code>/sys</code> on Linux.
 			</p>
 
+			<h3 id="ulimit">ulimit</h3>
+			<p>
+				It should have been something like cgroups/Plan9-namespaces, instead you get broken-by-default soft limits which can be overridden at any moment by applications, therefore useless. And hard-limits that can realistically only be set per-user/per-group.<br />
+				Ever wanted to limit the usage of <em>one</em> software, like say the memory used by the browser? Well you can't with limits, and apparently cgroups have side-effects…
+			</p>
+
 			<h2>See Also</h2>
 			<ul>
 				<li><a href="https://utcc.utoronto.ca/~cks/space/blog/unix/CLibraryAPIRequiresC">The Unix C library API can only be reliably used from C</a></li>