I don’t get why XeLaTeX didn’t automatically obviate all the others by now to begin with, at least for any greenfield applications.

(I use tectonic now but had been using XeLaTeX for more than a decade before.)

Non-ruby dev here. Can someone explain the side exit thing for me?

> This meant that the code we were running had to continue to have the same preconditions (expected types, no method redefinitions, etc) or the JIT would safely abort. Now, we can side-exit and use this feature liberally.

> For example, we gracefully handle the phase transition from integer to string; a guard instruction fails and transfers control to the interpreter.

> (example showing add of two strings omitted)

What is the difference between the JIT safely aborting and the JIT returning control to the interpreter? Or does the JIT abort mean the entire app aborts (i.e. I presumed JIT aborting means continuing on the interpreter anyway?)

(Also, why would you want the code that uses the incorrect types to succeed? Isn’t abort of the whole unit of execution the right answer here, anyway?)

Dynamic languages will allow a range of types through functions. JITs add tracing and attempt to specialize the functions based on the observed types at runtime. It is possible that later on, the function is called with different types than what the JIT observed and compiled code for. To handle this, JITs will have stubs and guards. You check the observed type at runtime before calling the JITted code. If the type does not match, you would call a stub to generate the correct machine code, or you could just call into the interpreter slow path.

An example might be the plus operator. Many languages will allow integers, floats, strings and more on either side of the operator. The JIT likely will see mostly integers and optimize the functions call for integer math. If later you call the plus operator with two Point classes, then you would fall back to the interpreter.

In this case, we used to abort (i.e. abort(); intentionally crash the entire process) but now we jump into the interpreter to handle the dynamic behavior.

If someone writes dynamic ruby code to add two objects, it should succeed in both integer and string cases. The JIT just wants to optimize whatever the common case is.

I’m assuming that when you talk about crashing processes as the status quo you’re referring to earlier versions of zjit rather than current Ruby on yjit? Because I’ve never seen a Ruby process crash because + was called with different arguments.

Yes; see the first ZJIT blog post. https://railsatscale.com/2025-05-14-merge-zjit/

I guess I’m confused why an actual add instruction is emitted rather than whatever overloaded operation takes place when the + symbol (or overloaded add vtable entry) is called (like it would in other OOP languages).

If all you're doing is summing small integers---frequently the case---it's much preferable to optimize that to be fast and then skip the very dynamic method lookup (the slower, less common case)

Presumably other languages with JIT do exactly the same thing?

The obvious solution is an ssh-agent integration that caches the touch-derived key for up to N hours or until the workstation is locked (as a proxy for user-is-away event), AND integrates with secure desktop (à la UAC) to securely show a software-only confirmation prompt/dialog for subsequent pushes within the timeout window.

(Tbh, a secure-desktop-integrated confirmation dialog would solve most issues that needed a hardware key to begin with.)

GitHub dropped http authentication so this only works for public repos (not that the UX or security of http auth for git is nice).

Can git be configured to use different keys for push and pull? (You can obviously use different upstreams, but thats not as elegant.) Most git servers let you specify read vs read-write privileges (aka “deployment keys”) so you could use one key to pull updates that doesn’t need touch and another key to push (which does).

GitHub did not drop http auth. They prefer you use http instead of ssh.

What they dropped was auth using your account name and password. You need to use a token as your password or use an extra tool like their cli client to setup auth (but it sucks if you have multiple accounts).

You configure separate entries in your ssh conf.

    Host gh-auth
      Hostname github.com
      Identityfile blah
      User git

pushurl = gh-auth:freeCodeCamp/devdocs.git

Devil’s advocate: How do they map that data to a user when you are buying through a maze of resellers?

they dont, they try against all the keys, there are at most a few billion of them

see Dual_EC_DRBG

If Python is your baseline, LuaJit is certainly going to be overkill. But to answer your question: when and where latency matters. Web apps, text editors, etc.

The greybeards would do it with imagemagick, vips, or even ffmpeg. Gives you full control over the quality and you can script it, parallelize it, and more.

Not exactly the topic of discussion but also not not on topic: just wanted to sing praise for chrony which has performed better than the traditional os-native NTP clients in our testing on a myriad of real and virtualized hardware.

Chrony is the default already in some distros (RHEL and SLES that I know of), probably for this very reason.

Pedantically, a monotonic function need not have a constant first derivative. To take it further, in mathematics it is accepted for a monatomic function to have a countable number of discontinuities, but of course in the context of a digital clock that only increments in discrete steps, that’s of little bearing.

But that’s all besides the point since most sane time sync clients (regardless of protocol) generally handle small deviations (i.e. normal cases) by speeding up or slowing down the system clock, not jumping it (forward or backward).

SHA1 as a MAC for AES encryption is different from SHA-1 as a hash algorithm and remains secure, though there are of course better alternatives.