> “But if it can be stated in such a way that it is as intuitively clear as the other other axioms of set theory, then it will likely be accepted"
The internal/external logic of sets is exactly where Set gets confusing with computation.
Subsingletons (mere props) being choice theoretic is exactly where we have to resort to HoTT etc..
That shift in limitations from internal vs. external is a lens on many independence results.
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...
While I am explicitly avoiding the how, have any of you successfully been accepted to a batch while taking a job with industry overlap, but not application overlap by using pre-hire explicit PII agreements?Or does it pose too many issues?
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
The new Blackwell hardware combined with TensorRT-LLM and speculative decoding consistently can hit 1,000 TPS/user barrier, comparing to closer to ~250 TPS/user (out of 10k+/TPS on the server)
Is there something I missed, this looks more like 14.4 to 56 on a 64kbps backing channel modem story. I have no doubt that there are still massive gains to be found, but they seem to be using existing constraints more efficiently, not that fios is coming.
I don’t have the budget to work on the foundational model scale, but with a draft model 10x–20x faster than target and an 60-80 acceptance rate I can see how they could promise 750/TPS (with a lot of other hard work) but I would appreciate where I should look to figure out what I am missing.
Firecracker just has a ReSTful unix socket with a defined API and launches KVM vms with limited options.
For custom SMB I still think libvirt is a lower entry cost and may have transferable use cases to longer lived VMs, so you can just launch a qemu microvm[0] and use virsh and/or libvirt xml to set up the networking.
The ~400ms boot time of a qemu microvm vs ~120ms for firecracker may not be an issue for some loads, but qemu will also allow you a bit more density of placement than firecracker. qemu microvms will use a bit more memory individually, but they will also tend to use less real system memory with a larger number of microVMs.
It is all tradeoffs, and kata containers are yet another option that may apply depending on your use case.
You can run your own firecracker or qemu/kvm microvms on most instances that allow nested hypervisors, or on a local host. If cost containment is critical to you this is one possible way forward.
Really it just depends on if you want/need ReSTful control, or need to support short lived serverless functions, or if CLIs fit better and you many want to support full VMs.
They both are just Virtual Machine Monitors that targeted different use cases and decided on different tradeoffs.
Just be careful about hosting traditional containers and microVMs on the same system, that config is going to be problematic do to fundamental reasons that are too complex to properly address here.
[0] https://www.qemu.org/docs/master/system/i386/microvm.html
There are very real times where you have to support all 4 bytes, there are others where other drivers require you to restrict the domain of discorse.
It doesn't change the value/cost of bit casting in a language with arbitrary bit width languages, especially when combined with the fact that int overflows are detectable illegal behaviour and you have saturating and wrapping operators.
This is in addition to the ease of using packed structs I mentioned above.
A list of some advantages:
* Zig's arbitrary-sized integers have a fully defined ABI for padding
* Allows for strict domain modeling using them as platform independent refinement types
* Precise memory packing, allowing more utilization of register space etc...
* OOB compile time checks
* Bit masking optimization, where sequential changes to packed values are often merged into a small number of and/or masks
To move to a more information theory example:
DNA nucleotides (A, C, G, T) represents quaternary state pairs.
If you wanted to store an array of 1,000 DNA nucleotides, each symbol is one of 4 bases, requiring exactly 2 bits of information. The Shannon Information would be: 1000 * 2bits = 2000 bits.
With uint8_t this would take 8k bits, vs 2k bits of u2. That is 300% more for uint8_t.
It is still horses for courses, but as an example consider 12-bit sensor reading in a standard u16, the data type allows invalid states. To ensure safety, requires manual defensive logic throughout your program in the traditional C/Rust/...
That traditional model in zig:
fn processSensor(value: u16) !void {
if (value > 4095) return error.InvalidSensorData; // Extra logic branch
// ... logic ...
fn processSensor(value: u12) void {
// Zero validation boilerplate code required here
As an example, and I may be wrong, but I think you cant easily perform checked arithmetic or use standard overflow operations on individual C bit-fields without copying them out into standard standard types (like int), modifying them, masking them, and copying them back.
With Zig the invariant is maintained implicitly at the type layer, removing runtime validation branches, error paths, and testing code
Does it solve all problems, no. Is @bitCast, a zero runtime overhead, compile-time checked bit reinterpretation and [3]u8 \to u24 useless and silly, no.
utf-8 encodes code points in one to four bytes, it is byte oriented vs utf-16 etc. In zig u8 is a byte, and is also (by convention) a char, although there isn't an explicit char type in zig. Technically there are chars in languages that need all 4 bytes in utf-8, but almost all of them are historical or emoji's in utf-8.
24bits (3 bytes) in utf-8 gets you Chinese, Japanese, Korean. 16 bits (2 bytes) gets you Latin letters with diacritics, Greek, and Arabic scripts. With 8 bits (1 byte) getting you Standard ASCII etc...
There is a point you could make that it may have been better to use utf-16 etc... and that we should have dropped ascii/latin-1 support, but once again go up to the 'Basic Multilingual Plane' in your [3] and notice that is covered by 24bits (3 bytes) in utf-8 encoding.
Zig natively supports arbitrary bit-width integers, the ABI is defined and you could simply think it as a slice of the next larger backing integer.
The[3]u8 to u24 bitCast will simply be backed by a 32bit int, using the same ABI. As you have u1 - u65535, sometimes it can be multiple words.
The 24 Bits (3 Bytes) [3]u8 to u24 example is exactly related to utf-8 that covers all the languages but excludes the emojis.
There are very valid use cases when you want to limit utf-8 to U+0000-U+FFFF, and it is valuable if your language allows you to make those decisions.
Remember, in zig packed structs are just integers and integers are just a group of logically consecutive bits.
Arrays like []u24 do not have the same ABI, arrays are not bit/byte packed, are not universally LSB across archs etc..
The compiler isn't producing unaligned code, don't confuse the abstraction with the concrete implementation. And yes [8]u1 and [8]u8 are exactly the same size and shape, even though they are arrays.
My current project is parsing ELF/Macho files, I can easily have zero allocations in my hot path with zig, the same is far more challenging in C, so I am biased, especially with zig allowing methods on structs.
And yes, I do use that crazy casting to 0xdeadbeef and other ascii metadata that is in those files.
To be clear here, I am not trying to prove you wrong, this is one of the places zig is very different and (IMHO) useful. Especially with streaming data or where you have network ordering etc... It is so nice to only cast what you need to but it does take a little while to wrap your head around how this interacts with buffers which are not your native endianness. At least for me, once I figured out to separate the shape of those data streams from their values it was super useful.
This study seems to show that there are places where synthetic data, especially related to common crawl.
> Pure synthetic data remains non-advantageous over CC; notably, models trained on pure rephrased synthetic data will underperform those trained on CC at larger models.
But the tradeoffs seem to be different at large scale.
> Overall, these model scaling results suggest synthetic data appears comparably less favorable for pre-training larger LMs relative to its utility in data scaling scenarios. Despite outperforming training on CC, larger models are not as tolerant to a higher ratio synthetic data as larger data budgets. This observation aligns with practices where synthetic data is effective for smaller LMs or specific pre-training phases, but less predominantly used for the largest models.
How I am reading it is there are places where it is useful:
> Notably, any mixture involving synthetic data, or pure synthetic data (except pure QA), is projected to achieve a lower irreducible loss than training only on CommonCrawl.
But it also seems that on textbook scale synthetic data, they did show model collapse vs rephrased data.
> These results contribute mixed evidence on “model collapse" during large-scale single-round (n=1) model training on synthetic data–training on rephrased synthetic data shows no degradation in performance in foreseeable scales whereas training on mixtures of textbook-style pure-generated synthetic data shows patterns predicted by “model collapse".
IMHO there are some very specific areas where we aren't "data limited", like math, but as your reference states "Our work demystifies synthetic data in pre-training, validates its conditional benefits, and offers practical guidance."
Note the cost of 30% of the total dataset being synthetic, where the model starts amplifying the generator's biases, leading to a permanent degradation in downstream zero-shot capability on unseen out-of-domain natural tasks.
My takeaway is there is nuance where synthetic data is an amplifier and where it is a problem, and in my mind that paper demonstrates it will not solve the data problem in general.
Note that the OP uses "systemic rejection", while the paper does reference bias, it is in the precise meaning of the word.[0] And this is not targeted at the general public.
You may want to look into the 1990 GOPAC handout "Language: A Key Mechanism of Control" to understand why some groups would simply just weaponize any term that was substituted. Academic papers need to error on being precise, to be effective, not focused on handling the general public with kids gloves IMHO.
Edited to add, listen to Lee Atwater's 1981 Interview on the Southern Strategy for even more context.
It is a large reason they can mitigate vendor risk IMHO, offering different tiers of switches as an example without being held hostage by on particular switch IC vendor like many brands.
I do wish someone would take up comstar though, netapp bought and killed several jbod lines etc… to kill it before Oracle bought Sun and also killed it to protect their enterprise storage offerings.
NVMe-oF may be a possibility because there are FPGA IP vendors but without comstar there are some challenges IMHO.