In Thinking about about the Go Proposal Process , Russ Cox says thefollowing about changes to Go in "Prototypes & Experiments":

For most non-trivial changes it is helpful to understand them bytrying them out before making a decision. [...] We arrange to landlanguage changes on day 1 of a development cycle to maximize that window. But for large changeswe probably need a way to make prototypes available separately, togive even more time, a bit like the vgo prototype for Go modules.

If you have a machine with strict overcommit turned on, your memory allocation requests will start to fail onceenough virtual address space has been committed , because that's what you told the kernelto do. Hitting your strict overcommit limit doesn't trigger theOut-Of-Memory killer , because the two careabout different things; strict memory overcommit cares about committed address space , while theglobal OOM killer cares about physical RAM . Hittingthe commit limit may kill programs anyway, because many programsdie if their allocations

For reasons beyond the scope of this entry, I've recently becomeinterested in understanding more about when the Linux OOM killerdoes and doesn't trigger, and why. Detailed documentation onthis is somewhat sparse and and some of it is outdated ( eg ).I can't add detailed documentation, because doing that requires fullyunderstanding kernel memory management code, but I can at least writedown some broad overviews for my own use.

(All of this is as of the current Linux kernel git tree,

As part of my irritation with DNSSEC that led to me turning offDNSSEC in my Unbounds , I said onTwitter :

As a sysadmin, my view of DNSSEC is that life is too short for me todebug other people's configuration problems.

One fundamental problem of DNSSEC today is that it suffers from thefalse positive problem, the same one that security alerts sufferfrom . In practice today, for almost allpeople almost all of the time, a DNSSEC failure is not a genuineattack; it is a configuration

I tweeted :

It has been '0' days since DNSSEC caused DNS resolution for perfectlygood DNS names to fail on my machine. Time to turn DNSSEC validationoff, which I should have done long ago.

I use Unbound onmy machines, from the Fedora package, so this is not somequestionable local resolver implementation gettingthings wrong; this is a genuine DNSSEC issue. In my case, it wasfor www.linuxjournal.com , whichis in my sources of news because it's shutting down.

One way to view what can happen to your Unix system when you don'thave swap space is that it's one morecase of the Unix virtual memory system facing additional challengesbecause it is what I will call a non-uniform cache . In a uniformcache , all entries come from the same source at the same speed(more or less), can naturally be accessed as fast and as frequentlyas each other, and can be evicted or freed at the same speed andvolume. In a non

On Mastodon, I was tempted :

My home and office workstation have complicated networking, buttheir firewall rules are actually relatively simple. Maybe it'stime to switch them over from annoying iptables to the new shinynftables stuff, which might at least be more readable (and involveless repetition).

Feedback convinced me to not go that far. Instead, today I rewrotemy iptables rules in terms of ipsets (with multiple set matches ), whicheliminated a great deal of their prior annoyance (although not allof

Recently, Artem S. Tashkinov wrote on the Linux kernel mailinglist about a Linux problem under memory pressure ( via ,and threaded here ).The specific reproduction instructions involved having low RAM,turning off swap space, and then putting the system under load, andwhen that happened (emphasis mine):

Once you hit a situation when opening a new tab requires more RAM thanis currently available, the system will stall hard. You will barely beable to move the mouse pointer. Your disk LED will be flashing

In my entry on how sharing file descriptors with child processes isa clever Unix decision , I said:

This full sharing is probably easier to implement in the kernel thanmaking an independent copy of the file descriptor (unless you alsochanged how dup() works). [...]

Currently, dup() specifically shares the file offset between theold file descriptor and the new duplicated version. This implies ashared file descriptor state within the kernel for at least filedescriptors in the current process, and along