> 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

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.

[0] https://en.wikipedia.org/wiki/UTF-8

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.

[0] https://arxiv.org/pdf/2605.27371

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.