blog

commit: dec482d764bb5d8c44537e415d8fa577529f89e1
parent 739f2b57fa5102326a47d32f181a119ac62f1d60
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>