Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
1–10 of 14 posts
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#2>Specifically on Linux there are two system-wide sysctls: fs.nr_open and fs.file-max. (Don't ask me why one uses a dash and the other an underscore, or why there are two of them...)
Somewhere it should be lore that the person that named these syscalls went on to name functions in PHP.
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#3>Specifically on Linux there are two system-wide sysctls: fs.nr_open and fs.file-max. (Don't ask me why one uses a dash and the other an underscore, or why there are two of them...) Somewhere it should be lore that the person that named these syscalls went on to name functions in PHP.
The creat(3) tradition lives on.
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#4>Specifically on Linux there are two system-wide sysctls: fs.nr_open and fs.file-max. (Don't ask me why one uses a dash and the other an underscore, or why there are two of them...) Somewhere it should be lore that the person that named these syscalls went on to name functions in PHP.
The creat(3) tradition lives on.
That extra "e" would represent a 20% bloat in the functions name, bytes aren't free you know.
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#5Earlier quoted context omitted.
The creat(3) tradition lives on.
That extra "e" would represent a 20% bloat in the functions name, bytes aren't free you know.
And yet people will die on a hill defending using X number of spaces instead of a single tab for indentation (where X is some positive integer, usually 2, 3, 4, or 8), with zero regard for the bytes wasted.
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#6What doe NR stand for ?
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#7What doe NR stand for ?
Probably NumbeR.
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#8Earlier quoted context omitted.
That extra "e" would represent a 20% bloat in the functions name, bytes aren't free you know.
And yet people will die on a hill defending using X number of spaces instead of a single tab for indentation (where X is some positive integer, usually 2, 3, 4, or 8), with zero regard for the bytes wasted.
This is what happens when you reject S-expressions as the only true form of syntax. People will keep arguing all kinds of nonsense, for the same reason that in logic, falsehood can be followed by anything you want.
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#9What doe NR stand for ?
I've seen it used for (the local equivalent of) "number" in various countries.
Re: Background of Linux's "file-max" and "nr_open" limits on file descriptors (2021)
#10Earlier quoted context omitted.
That extra "e" would represent a 20% bloat in the functions name, bytes aren't free you know.
And yet people will die on a hill defending using X number of spaces instead of a single tab for indentation (where X is some positive integer, usually 2, 3, 4, or 8), with zero regard for the bytes wasted.
Different people? Original C and Unix software projects used hard tabs for indentation, and that carried forward into the age of the BSDs. Almost all Unix ecosystem software was tab-indented until relatively recently. Some GNU projects were notable early exceptions, though using spaces for indentation was the least objectionable aspects of their indentation style, and more understandable in that context. By my recollection, it was the increasing popularity of C++ in the 2000s, which was at that time centered around Windows stylistic culture, that initially brought the proliferation of soft tabs to Unix/Linux, followed shortly by the Python community, which for whatever reason gravitated toward soft tabs notwithstanding the earlier preference (including that of Guido) for hard tabs.
It's not obvious in modern editors or code browsers, but the Linux kernel, much (most?) of the base Linux user land, and the various *BSD projects (kernel and user land) still use hard tabs for indentation.