Doesn't seem to be updated for Tahoe yet, and even the Sequoia version isn't notarized, so it's not really clear if it has a future.

It cuts both ways: the employee can walk out during the trial period for reasons such as feeling like they didn't fit in, or the work being different from what they imagined. But if they merely find a better-paying job elsewhere, they cannot invoke the trial period but have to give notice in the usual way.

I would assume that your local audiologist or music instrument store will know what the U.S. equivalent to these is. It seems to me that Elacin's biggest market is musicians who want a comfortable pair of earplugs with a flat frequency response.

https://www.elacin.com/your-perfect-fit/leisure/relax-sleep/

https://www.elacin.com/your-perfect-fit/leisure/relax-sleep/

Currently I use Ozlo Sleepbuds which are not quite as comfortable and a little finicky to operate, but I like the masking noise.

When the model has the wrong solution in its context, it will use it when generating new code, and my feeling is that it doesn't handle the idea of "negative example" very well. Instead, delete the bad code and give it positive examples of the right approach.

https://x.com/mbalunovic/status/1907436704790651166

TeX's design was finalised in 1982, when the computational resources were different by a few orders of magnitude. There is a very strong culture of backward compatibility (search for "A torture test for TeX") and there are so many equations written in TeX documents that it would be impossible to change the parsing now.

That said, something like MathJax would be free to create their own TeX-like syntax where parentheses are automatically paired.

I for one often find myself wanting more control, writing `\bigr]` or `\biggr]` instead of `\right]` to get the rendered equation to look good.

> And while rendering `(a+b)/a` as a `\frac` is opinionated, honestly, the only reason why this occurs in my notes is when I was too lazy to type `\frac{}{}`.

Plain TeX has the much nicer syntax `{a+b \over a}` but for some obscure reason LaTeX recommends against that.

https://www-cs-faculty.stanford.edu/~knuth/news08.html

I registered for their Postmaster Tools, which says

    No data to display at this time. Please come back later.
    Postmaster Tools requires that your domain satisfies certain conditions before
    data is visible for this chart. 
    Refer to the help page for more details.

Outlook was even worse, and I just told my Outlook users to change providers.

Eventually I capitulated and got Google Workspace, and now everything gets delivered perfectly.

https://www.tandfonline.com/doi/abs/10.1080/00029890.1976.11...

which has the curious property that as you substitute nonnegative integers for the variables, the positive values of the polynomial are exactly the set of prime numbers. (The polynomial also yields negative values.)

When put like this, it sounds like the polynomial must reveal something deep about the primes... but it's another cool magic trick. The MRDP theorem (famous for solving Hilbert's 10th problem negatively) implies that this kind of multivariate polynomial exists for exactly those sets of natural numbers that are computably enumerable, so the polynomials could be seen as a really esoteric programming language for set-enumeration algorithms.

More tricks: https://en.wikipedia.org/wiki/Formula_for_primes

That one also lets you look up other weeks by number, which is occasionally useful. But the calmer design of https://vecka.nu is very pleasant!

Yet another fun fact: with %V week numbers, the date 2024-12-30 (December 30, 2024) was 2025-W01-1 (the Monday of week 1, 2025). Thus strftime needs two different ways to specify the year: %G denotes the year that goes with %V week numbers, %Y denotes the year that people usually think of when they ask "what year is it". Unfortunately %G comes before %Y on the strftime man page, so people who scan the page quickly can easily pick %G when they really want %Y. I've seen a few bugs caused by this.

I have also seen the corresponding bug in SQL, using IYYY instead of YYYY. This boggles the mind, but apparently when some people read "ISO 8601 week-numbering year", they only see "ISO 8601 ... year", think "yes, that's the date standard we use" and don't care about the "week-numbering" word in the middle.