Intel introduced the RAT (Register address table) with the P6 in 1995. Although IIRC it depended on ROT(Register Order Table) and wouldn’t affect the outcome the same way.

I think Netburst is where it really was extended to support out-of-order pipeline stages.

As long as the CPU does’t violate the interface contract it can micro-optimize at will.

Because modern CPUs have hundreds of hidden physical registers, the CPU's Register Renaming unit looks at those forced stack move instructions, realizes they are just recycling the same local variables, and maps them to hidden hardware registers anyway. The CPU essentially executes the "stack spills" at the hardware register level, rendering the compiler's bad register constraints almost completely harmless.

Particularly the siphash result makes me think this is what is happening.

Unfortunately I don’t think there is a way to observe this as a consumer.

With a few warts of course, but not like back then.

Even on MacOS, save this as `doc.tr`

     .\" Index Macro
     .de IX
     .tm \\$1^\\$2^\\n%
     ..
     .\" Content
     .sp 2
     This is the first page.
     We are talking about the history of Unix.
     .IX "Operating Systems" "Unix"
     .bp
     This is the second page.
     Here we discuss the C language.
     .IX "Languages" "C"
     .bp
     This is the third page.
     We go back to talking about Unix.
     .IX "Operating Systems" "Unix"

     % groff doc.tr > output.ps 2> raw.idx

     % sort -t '^' -k2,2 -k1,1 raw.idx                    
     Languages^C^2
     Operating Systems^Unix^1
     Operating Systems^Unix^3

Even inserting the `.IX ...` lines on a string match in the troff file is fairly easy. But somehow they were parsing the typeset output, not sure what kind. But no need to try and track page numbers when typesetting languages do that for you.

TL;DR What I was saying is if you are using a typesetting language, use the tools in the typesetting language when possible. If you can do it in troff you can do it in LaTeX with makeindex etc...

But this email is a there because it is a bit of a feat of strength, thus why it was sent to the seders list. I wouldn't have used sed for all of this at the time, and I am wondering what they were using for publishing in anyway. In 1997/2001 I would have just taken text inputs and used LaTeX, and even indexes with troff was easier.

QuarkXPress and Pagemaker were very popular at that time, with QuarkXPress having almost all the commercial market in the 90s, so they must have been using something very specific for this religious market.

But also note that VS Code/ides with Vim keybindings is extremely popular among modern software developers, so while they may not call sed directly they still use it with `:`

That is the same reason we used it in the 80-90's, you had sed, vi, ed, etc... that were at least usable without much pain across all the drift of the UNIX wars.

But I am really curious on why this email even existed at all, it doesn't make sense outside of someone playing with UNIX/Linux as a side quest, unless they were *troff/TeX based?

Flock is building a giant camera network that records people’s comings and goings across the nation and maintains those records despite any link to crime for an indeterminate amount of time.

The other players like Axon and Motorola are looking to follow Flock's lead, but mass surveillance is the main problem.

Quantization + KV cache paging + speculative decoding (MPT or draft) is a fairly good mixture here.

Some examples as I don't have access to run tests on a 5060ti right now:

     https://njannasch.dev/blog/gemma-4-mtp-vs-qwen-speculative-decoding-5060ti/#vs-qwen-36-mtp

     https://www.reddit.com/r/LocalLLM/comments/1umw7vj/dual_5060_ti_16_gb_llm_inference_performance/

     27.21.533.298 I slot print_timing: id  0 | task 7843 | n_decoded =   1780, tg =  62.15 t/s
     27.24.537.173 I slot print_timing: id  0 | task 7843 | n_decoded =   1965, tg =  62.10 t/s
     27.27.541.142 I slot print_timing: id  0 | task 7843 | n_decoded =   2152, tg =  62.11 t/s

That said, even the foundational models fail at the hard parts of my code so I use it opportunistically.

I have reduced down to just using zed, will three locally hosted models.

Qwen 3.6 27b on 1x3090 llama.cpp with 128k context ~50tps

Qwen 3.6 35B-A3B on 1x titan v + 2x1080ti llama.cpp with full context ~30tps

GPT-OSS 120b on pure cpu (slow)

I just use zeds parallel agents, task switching, stopping and fixing the code when a model gets stuck.

This still lets me stay engaged, and to modify code to be maintainable etc…

It gets me 80% there and I use to keep a subscription but often times just using googles AI mode is just as good.

That said I have 30 years of experience and insist on knowing how my code works, so this gets me 80% of the short term benefits while not depending on a 3rd party to keep my code moving forward.

Your mileage will vary and 2*5060ti 16gb cards would get around 100/tps with Qwen 3.6 35B-A3B on cards that are widely available.

To be honest the more modern cloud models are using draft tokens etc… that while they are superior for common coding tasks are degrading with more domain specific tasks.

That is just the cost of the draft model being ~10-20% of the foundation models size, and even the biggest Blackwell GPU is limited to ~250/tps so MoE or draft models are required for scaling performance at the foundational level IMHO.

The hard part is my use case are the OOD or small examples in corpus level, the above hurts there.

A Lamborghini may be nice, but I personally need a minivan more.

> "I learned cursive as a child. Then I went for many years without using it much, and forgot some of it."

While fountain pens may be nicer for cursive, they were very late in the games only coming into the scene in the late 1800s, long after fashion had been set.

In the US we were taught either the Zaner-Bloser or the D'Nealian alphabet, and while most of the claims of cursive over manuscript are typically overblown and fall under scrutiny, with common use it may not be faster, but is easer for (the small sample of friends I have asked) to write while not looking at the paper. Not faster, but easier to write in strait lines without looking (in my experience).

Manuscript (now called printing) wasn't common when Zaner-Bloser printed the book "The arm movement method of rapid writing"[0] IIRC.

But for business writing (which both Zaner-Bloser and D'Nealian were targeting) it is not so much the fact that you aren't lifting the point, but that you are using your whole arm.

The scientific claims of Zaner-Bloser are almost certainly suspect, but before word-processors, taking notes while not watching your writing was a critical skill, or was in my experience.

That is a very different world that the scribes of old, or even Roman cursive, which would have only had quills, and which did not really connect letters.

If you look into secretary hand, italic hand, and court hand, a lot of it had to to with style and preferences, with the US Declaration of Independence being in Secretary Hand, which had been in fashion for official docs for centuries at that point. Shakespeare also wrote his plays Secretary Hand, while ladies of the era would have used 'Italian style' italics.

So unfortunately it seems there are many back explanations, the real history is clear as mud in the absence of direct evidence, or more correctly, claims like in Zaner-Bloser.

[0] https://archive.org/details/armmovementmetho00zane/page/n3/m...

> Personal data we collect or receive to train our models

> • Data that our users or crowd workers provide, including Inputs and Outputs from our Services (unless users opt out)

> • Feedback that users explicitly provide about our Services

> • Materials flagged for safety, security, or policy review

While I don’t have visibility into individual corp contracts, hitting tab on a FIM is ‘feedback’, so it is not so clear cut.

The earlier issue with finger was due to manufactures having brain dead firmware and using AT commands for voice features in the 14.4 modems etc... I can't seem to find it in the usenet archives that are still around, or at least with current search engine tuning.

In gold it changes the color, in Mercury it changes freezing temperature.

Gallium has a low melting point 29.76C but that is due to unique chemical bonding.

"relativistic contraction" (shrinking of s and p orbitals) and "relativistic expansion" (destabilization of d and f orbitals) causes many observed phenomena.

Relativistic contraction of the 6s orbital and expansion of the 5d orbital lower the energy required to excite electrons. Consequently, gold absorbs blue light.

Strong relativistic contraction of the outer 6s electrons leaves them tightly bound and unavailable for metallic bonding. This results in incredibly weak atomic interactions, thus mercury a liquid at room temperature.

Lead also has 6s, which is what makes lead acid batteries work as well as they do.

So while the observed effects change, there are relativity effects with several nearby neighbors.

     echo “+++ATH0” > ~/.plan

[0] https://onlinelibrary.wiley.com/doi/epdf/10.1002/anie.201302...

Or does it pose too many issues?

Comments URL: https://news.ycombinator.com/item?id=48861692

Points: 1

# Comments: 1

Physics uses the properties of unitful objects to help avoid errors, it is a convention and not (by itself) a fundamental truth.

If your world is physically realizable one, the benefits make this choice a no brainier, but it is still a convention with some convenient outcomes.

A unitful quantity is actually a tuple, specifically (value = quantity x unit)

In computer science and programming, assuming a priori that individual scalers are only useful in the context of units, or that they will behave in the same way can cause you real issues.

Be careful with conventions and assumptions, use them where they serve you well and avoid them where they block you from finding useful mechanical means to solve problems.

In this example temperature would be a magnitude, not a unitful value.

At least in the ISO 8000whatever convention where a value is the product of a unit and a magnitude like most people are use to.

Here is a Terry Tao post with more information[0] on why the convention is there, but as he mentions, in differential geometry and Clifford/Geometric Algebra you do things like add vectors to scalers all the time.

[0] https://terrytao.wordpress.com/2012/12/29/a-mathematical-for...

We also had a bunch of 1000 and 1000a's, and an AlphaStation running AltaVista firewall all on NT.

An ALR 6x6 (6* Pentium Pros) was faster for Windows than the fully loaded out AS4100 IIRC. Except that the 4100 supported more memory and PCI slots IIRC.

Neal Ford calls this a distributed monolith because a change to a database schema can break every single service at once, but there are very valid uses of this method.

There are decades of books on the foot guns as we used this even back in the client-server days.

One suggestion I have is to research where the first version of SoA failed, especially as these systems tend to erode into Enterprise Service Busses.

Products like Apache airflow tend to have value not because of the persistence layer, but because they force workflows into DAGs, which is an enforceable structural constraint, while SQL, being declarative, can sometimes force you into trying to enforce governance through observing behavior.

The former is not subject to Rice’s theorem, while the latter is.

If you actively control for these it will greatly increase the lifetime of this system before (or if) you reach the point you have to replace the system.

Fedora and selinux may be a thing to look into if you were trying to share volumes.

I am posting this from a park on my phone, so this may be slightly wrong, but this is the multiarch case that seems to be harder to find for many people.

      podman manifest create my-image:latest
      podman build --platform linux/amd64 --manifest my-image:latest .
      podman build --platform linux/arm64 --manifest my-image:latest .
      podman manifest push my-custom-image:latest docker://docker.io/user/my-image:latest