Eval differs very slightly from, say, an interpreter with a very non-syntactic AST, due as you say to homoiconicity. Neither read, print, nor loop differ in any Lisp-specific or qualitative way. And the differences in eval’s behavior don’t change anything significant about the REPL user’s experience (other than that they’re writing Lisp). So what do you mean?
Specifically, cached state and behaviors still need to be reconciled with new inputs/overrides during “eval”, and no Lisp has an easy answer to those (neither, as far as I know, does any other language). Avoidance of closure state via late binding and a convention of reliance on very simple data structures help Lisp’s REPL/hot-patch story, and that is indeed nice, but it’s far from “guaranteed ease/safety of REPL patching” or a totally different paradigm.
Slightly off topic, but it is worth being familiar with AWSCLI’s built in jmespath JSON transformation system. That saves on the need for jq in a lot of cases. Given that awscli bundles that, I generally forgive it for defaulting to JSON (especially given how deeply nested and interlinked many AWS API results are), but reasonable minds can differ. AWSCLI’s schizophrenic use (or not) of pagers for tiny results, on the other hand, is less defensible.
I wrote GGP as a Lisp user and enjoyer—not pretending to deep experience, but definitely am well acquainted. And neither the REPL nor live reloading are important differentiators. Neither is the ability to attach a REPL to a running program: plenty of languages have that built in (Erlang, Ruby), and many others support it through popular third party tooling (e.g. Pyrasite for Python, and—ironically—the class executor for the Clojure REPL for arbitrary non-Clojure JVM programs). Many Lisps’ REPL tooling is very nice, and the language lends itself well to REPL-oriented development. But those aren’t “uniquely Lisp” features as you and many others claim.
There are some truly powerful and unique things about Lisps, but I wish articles like this would stop including REPLs and hot-reloading. The former have been table stakes for interpreted languages (and some compiled ones!) for years, and the latter is neither unique nor particularly widely used (hot reloads have to tangle with state and patching, so resetting the world for ease of reasoning is considered a best practice for a reason).
I interpret that the opposite way: if a huge spam campaign can be run by a guy in his bedroom, there’s no way that larger spam operators can be effectively killed by legal action. They’ll just employ different guys in different bedrooms. The same thing is true with phone phishing scams—they’re not individually hard to eradicate, but the combination of lucrativeness and rapid-rebootability means that legal crackdowns in the past have not been effective at scaring the rest out of business.
> Can you send mail from something that doesn't have a DNS entry?
I hope not. Just like SSL, I think requiring a registrar+DNS server to vouch for a durable identity is an important barrier to abuse (and an important intervention point for violation reports).
I don’t think they can. Spam, like speeding on highways and drug sales, is such an asymmetric enforcement area that I have very limited confidence that legal enforcement would make a significant dent in the volume. It’s far too technically easy to anonymously, repeatedly break anti-spam laws. This is an area where consortium enforcement (like the big inbox providers pushing solutions like DKIM2) is probably the most effective.
Don’t get me wrong, there are tons of areas where countries’ legal systems have no excuse for not enforcing the law more stringently (e.g. flagrant corruption in multiple regulatory bodies’ failure to enforce investment/wire fraud). But spam is part of the other category—technically difficult enough to crack down on that legal action is a waste of time. There are ways to change that, but they’re all either more centralization-prone, worse for privacy/liberty, or extremely expensive.
Other BSDs don’t have that, but have equivalent PCI tree identifiers. “hostid”, too, is found on many systems but is much less unique as it’s often a function of local network address.
Yeah, crash ballast is an extremely underrated tool.
It also works for the OOM killer: run a daemon with a child process that holds some fixed amount of memory. Adjust OOM scores of everything else on the system lower than the child. If the parent’s waitpid() returns due to an OOM kill, send an alert/shutdown nonessentials/sync buffers to disk and so on.
Sigh. Malloc failure should have had to be trapped with a signal or something, not just a return status. I know, I know, threads and nesting handlers make that hard and historical precedent makes it impossible to retrofit, but I can still dream.
The issue is that there’s no generally correct behavior. Should a database under memory pressure stay up at all costs even if it becomes unusably slow (by e.g. nuking 99% of the buffer cache)? Or should it crash/failover hard with a likelihood of potential recovery afterwards, even if it technically could have stayed up? Something in between?
There’s no correct-in-general answers to those questions. This is a hard problem due to context dependence; that’s why there are so many knobs.
Well written, but I do not understand why this is news. A thread will deadlock if asked to wait on itself, and that generalizes to any fixed size group of threads. That seems like it should be obvious to everyone.
The standard guidance of avoiding join() without a timeout, only running leaf-like/bounded work on TPEs, considering common executor instances to be best-effort when it comes to important work, and of using (formally or informally) structured concurrency and purpose-specific executors with carefully managed lifetimes, watchdog timers, and ovservability is important. Given their skill at writing, I’d love for the author to tackle those in their next post; this one’s subject seems trivially-well-known.
Then how was the Asahi team able to load their own firmware? I was concerned about that process--whatever it is--being something apple might lock down. If it's already likely locked down to Apple's satisfaction, that's good news.
It’s the difference between “there’s no published standards other than the reference implementation for some of the API” and “there’s no published standards and extremely monolithic reference implementation design coupled to proprietary blobs and considerable effort spent on signing/boot chain authentication to prevent third party implementations”. Apple is currently the former.
> The firmware loaded by XNU is not verified by the CM3. It will begin executing from its reset vector when signalled, no matter what is actually there. What if we just… used our own firmware?
Without taking away from the unutterably awesome achievement of writing custom firmware against a proprietary moving target, I worry about this one specifically. While Apple will hopefully continue the practice of not going out of their way to break third-party OSes, it doesn’t seem unlikely that they will introduce hardware signing for firmware blobs or the data they supply at runtime when programming the hardware; that’s a reasonable security concern for Apple to address. I hope this gamble pays off though!
EKS can get pretty damn big, well into the thousands of nodes without much special tuning, and beyond that with some care and control plane monitoring. Expensive, though.
> lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurrent connection.
Pg connections are definitely heavy, but usually on resources other than memory in my experience. If you configure reasonable dirty reclamation and recycling, the memory numbers are often overstated due to Linux tools’ deceptive fork accounting and shared buffers. Ofc, if you’re averaging lots of heavy queries per connection it’ll be truly heavy, but many times the numbers overstate the impact.
he/him
github.com/zbentley
blog.zacbentley.com