I remember playing with my father's collection of tape recorders when I was young and one of them had such a "cat's eye". Maybe that's where my love for glowing phosphors started.
My father had one as well, an old Magnecord unit packaged into a wooden case with transport and preamp, with the preamp having one of these tubes. Nevertheless, it was also fitted (perhaps by the dealer) with a proper VU meter. I learned the basics of recording on that, which served me well at a variety of times.
Naturally, his FM tuner from that era also had a horizontal magic eye tube.
At this point the American people have no additional say, except indirectly through congress. Barring an impeachment with a successful conviction (extremely unlikely without a blowout loss for the republicans in November), the man will "serve" the rest of his term whether we like it or not.
Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.
For the curious, this is technically possible in Rust using a dynamically sized type [1], but in practice is difficult and doesn't really play nice with the rest of the language. The nomicon entry concludes with "Yes, custom DSTs are a largely half-baked feature for now." [2]
Unfortunately, Rust is not a good choice for this kind of tricks. This is where Zig shines. In Rust, you can’t even use proper arenas, which can help a ton with allocations.
Cloudflare started to pick Zig recently, for projects, that have memory constraints.
You definitely can and this is done a lot. What you might mean is that you can't use standard library's collections with them (this is getting stabilized soon!) and have to use third-party, but that is a different thing than "can't use arenas".
> Rust is not a good choice for this kind of tricks.
Rust can do those tricks, but it's true that it is hard than in C or Zig. That said there are often crates to help.
You can’t allocate collections without nightly or without reimplementing them in the library. Every implementation uses it’s own set of trade offs to provide safety in unsafe implementation.
Rust supports arenas just fine ( https://crates.io/crates/bumpalo ), and if you mean the support for using custom allocators in the standard library collections, that's as stable as Zig is.
I wish more programming languages implemented record types as seen in databases, where dynamically sized fields are packed into a contiguous area of memory.
The CloudFlare manually implemented a clumsy version of this.
Wouldn’t it be nice for the compiler to manage this for you in the same way that your database engine does when it saves a “row”?
> dynamically sized fields are packed into a contiguous area of memory
Are you able to explain this? Do you mean an N sized array where each entry is either a value or a pointer to a value where the 'pointed-to' values are after the end of the array?
I'm trying to underatnd how you'd do this without having to parse M-1 elements to get the Mth entry if you did a [{size0, value0}, ....., {sizeN, valueN}] arrangement
There are various ways of implementing this, someone from a C programming background mentioned on option where the heap-allocated record objects aren't fixed size structs, but instead the allocated space is dynamically sized and the struct is just a prefix.
Physically the compiler would generate something like:
struct FooRecord {
long __length__;
int fixed_sized_field;
char some_other_field;
char* first;
char* last;
char* title;
}
Where 'first', 'last', and 'title' are sequentially stored after the struct in the heap memory.
There are variants of the above, of course. Instead of pointers the compiler could use lengths, offsets, or a pointer to the end of the variable length field -- this works because the beginning of the first field is at a fixed offset, and then pairs of pointers delimit the rest.
You can rely on the heap allocator to track the "__length__" instead, or you can encode it into the record explicitly to make "dynamic sized copies" simple.
Windows APIs generally work this way! You create a buffer, put a length in the first field, and then the API call writes a fixed-sized prefix followed by the dynamic-sized fields into the buffer. The 'length' is replaced too, so you know how many bytes to copy out without having to understand the structure.
Database engines go one step further and pack multiple "records" into a single "row". They typically store the fields "packed" at the start of the row with 16-bit length or offset markers at the end for the various dynamic sizes.
Something like:
fixed_sized_field // Row #0
some_other_field
first
last
title
fixed_sized_field // Row #1
some_other_field
first
last
title
... empty space ...
next_offset // always populated
row#1_title_offset
row#1_last_offset
row#1_first_offset
row#1_offset
row#0_title_offset
row#0_last_offset
row#0_first_offset
row#0_offset // typically the constant zero
The idea here is that every length is the difference between pairs of sequential offsets. I.e. row#1_title has length (next_offset-row#1_title_offset).
Thanks for such a thorough reply! I initially thought you were describing flexible array members, but this sounds like the ability to have different types/members concatenated
I think they mean the cache entry is a collection of dynamically sized fields. It would be nicer to store that as a single contiguous allocation, rather than a bunch of pointers to individually allocated dynamically sized items. At least in this case, it might.
In a row oriented database, you get a contiguous spot for the whole row even when there are multiple variable width fields.
Depends on how the CacheEntry is stored, it's probably stored in a slice of &[CacheEntry] which precludes storing the record data alongside it as the size of each entry must be fixed.
Even in C, if you want differently sized data to be indexable in O(1), you're stuck leaving them as pointers. You definitely could just have a variable-sized area for this, but that level of optimization is pretty seldomly done in C.
If you define Europe as Sumer or Egypt, then yes. If you define Europe as Rome, then no. The earliest deciphered Greek writing dates from 1450 BC (Linear B) but that civilisation fell in the Bronze Age collapse and there is no (written) continuity with Europe as it stands today.
As far as I'm concerned we're all equally ancient descendants from LUCA.
One way would be to toy with the order in which the text appears on the page: that needn't be in the same order as the one for the text in the document. I.e.: the text on page could be "hello world" whereas if you copy it you get "old row hell".
Or use a bunch of fonts shuffling letters. So the text on the page and ASCII text under it do not match
Otoh, how do LLM read PDFs? Text is likely to be shuffled anyway from my experience. Do they not (simply) OCR? But then the white font trick won't work.
Anthropic (and Google) now embed information in text, via 256bit keys, word selection, or whatever. But I wonder what the potential for theoretical abuse is here. Encrypting prompt injections, for any conceivable purpose seems a lot more viable now than it once did. Got me thinking.
> “What the plaintiff did here was to use that new tool in a dishonest way. A filing is a communication to both the court and the opposing party. Its integrity rests on the simple premise that what the reader sees is what the filer wrote
... but the black text is what's supposed to be read by humans.
> and that the filer refrains from transmitting, at the same time, a second and hidden message engineered to change how the filing is reviewed or potentially judged,” Spader added. “Our system rests on the premise that what is said to influence a decision is said openly, on the record, where the other side may hear it and respond.
But if the white text influences the decision, isn't that an admission of use of LLM by the judge to make the freaking decision?
I would've had more faith in the judge if he said electronic filing must be a faithful representation of the filer's argument, so no mangling like "hello world" to "old row hell", and anything otherwise (adding words in the electronic version, or making the files unreadable) is something akin to "obstruction of justice".
Which of course would have wider repercussions for people who print PDFs and rescan them without OCR because they want to e.g. obscure a politician's links to a pedophile financier...
I'm not sure which country you're from, but many EU countries do have private health insurance. The Netherlands, for example, has a system of subsidized private insurance, and a mandate that everyone buy a policy.
(If Americans are thinking, "huh, that sounds like Obamacare / the ACA marketplace!" then you're right.)
Painting in such broad strokes, the German system also sounds like the ACA, but it's really not: the high level description really erases key differences.
In Germany there is nothing like bronze/silver/gold plans. All statutory health insurance covers what is required to be covered by regulations, with just a few bonus services, at the regulated tariff plus just a few percentage points of variation. So the 90% of people in Germany who have statutory health insurance [1] have essentially the same coverage. The tariff is a percentage of income (up to a cap), not a flat fee.
[1] not everyone is required to have statutory health insurance, for example employees above an income threshold and self-employed people
The Dutch system and the U.S. system are not comparable. Health insurance in the U.S. is a “free market” that the government dabbles in with a little policy here and there. Health insurance in The Netherlands is controlled by the government, it is heavily regulated.
Healthcare is "free" across Europe, including in The Netherlands. The choice of The Netherlands' to structure their system as mandatory insurance doesn't change the nature of it, it is free at the point of service with the mandatory insurance costs paid for by the government when someone is unable to pay themselves.
No matter your mental gymnastics that is not how those Americans imagine health care in Europe works. And just for your (and our confused American friends) information there are several countries in Europe where "a point of (healthcare) service" will send you a bill.
Which European countries have a healthcare system similar to the American system? A system that has "insurance" (e.g: The Netherlands, Germany) is no less "free" healthcare than a system without insurance (e.g: England) or a system that will "send you a bill" like France. "Free" healthcare means that the patient will never need to worry about the cost of their treatment because it is covered by the system (whether through taxation, reimbursement, insurance does not matter). How many people have been bankrupted by healthcare in Europe?
The European/"Socialist" solutions are never obvious to Americans.
It is like parliamentarianism, campaign financing regulations, gun control, multiple political parties, etc. Americans call these things "Socialism" and then freak out about them and refuse to see any good on them.
... and "Chat Control" and Digital ID and forcing digital currency and persistent digital surveillance and conceding your national sovereignty to a council that can pass binding laws without your consent and ....
Let's not pretend either system is perfect, or that the _underlying principles_ that both systems hold are the absolute correct way to organize a society.
Americans have be primed with _decades_ of rugged individualism and the idea that collective action is inherently weaker/flawed (just don't think about Social Security). It might have been reasonably true 100 years ago that everyone could pay for their own health care, but we're now in a world where the average person is perpetually on medications that are expensive to produce, and will demand increasingly expensive medical interventions throughout their life (heart health, cancer care, etc.). Combine that with AI probably wiping out a ton of industries/jobs - something has to change. I'm not going to pretend to have a solution, but I think it is disingenuous to suggest any EU nation has it figured out either and is obviously correct.
While Americans have been primed, it's still relatively new. If any of the new deal proposals were proposed today, everyone would lose their mind.
The dirty secret: half of what makes living in America tolerable comes from new deal policies. Everyone knows it, nobody will say it.
A similar thing goes for the ACA. Republicans hate it, but at the end of the day Americans don't want to be dropped from their insurance plans for having cancer or some genetic defect. Literally nobody wants that, only out-of-touch political talking heads want that.
That's not to say any of these policies are perfect, they all have flaws. But if you ask the American people what they want but carefully never name policy names, it becomes obvious everyone is on the same page.
Just a minor clarification: The Money freaks out, calls these things "Socialism" and then dumps billions on red-baiting campaigns and political donations to defend the (highly profitable) status quo. Most citizens would just like some healthcare.
The issues around zoning are not comparable. For one, here in the Netherlands we have plenty of density and not a lot of missing-middle, but still a giant shortage.
The problem here was never zoning, it was a lack of building.
> problem here was never zoning, it was a lack of building
Why isn’t the latter an effect of the former? I believe the Netherlands restricts building height by parcel unless a deviation procedure is granted, something I understand to be expensive and risky.
For one, Cities in the netherlands are already quite dense, and the dutch are focused on building family houses attachted to each other mostly (row housing).
Also, thanks to the massive agricultural sector and a lack of oversight on industry, the netherlands has a massive problem with nitrogen in its soil which prevents building because building stuff generates more nitrogen.
Speculation and the liberalisation of the housing market has also massively contributed to price increases.
This is news to me and interesting re: nitrogen crisis. That said, isn’t construction a very minor contributor relative to the agricultural nitrogen impact? Like, taken to an extreme, preventing construction based on this is like preventing people from having children because children will produce nitrogen compounds
The nitrogen problems has been ignored for so long and nitrogen compound deposition has been so intense for a long time that you can't really do anything anywhere without depositing nitrogen compounds in an area already suffering from the environmental effects.
The Netherlands is a very densely populated country compared to the most of Europe. Furthermore, there are industrial hubs bringing in polluted air through the wind from the west, south, and east, making up a significant source of the nitrogen compound deposition. All efforts to solve the problem have so far upset very powerful lobbyists whose income relies on being allowed to pollute more to stay ahead of the competition (not to mention caused violent protests).
There are many factors to the housing problem, it's not just nitrogen compounds. In my opinion, the entire construction sector coming to a standstill after the 2008 crisis was probably what kicked off a storm of seemingly unrelated issues, from population pyramids to the water table levels to investors using property to accumulate wealth to hyperintensive farming practices.
New measures to supposedly solve the nitrogen compound crisis have been announced. By the looks of it, I expect the agriculture lobby to riot again, and new elections by the start of next year when the government inevitably collapses itself again in an attempt to use populism to gather more votes.
It’s expensive to build (many rules, not enough construction workers, expensive materials), expensive land, nitrogen policies, economic crisis 2008-2013 when there were no buyers for new houses caused a backlog of new houses.
reply