I've programmed C++ for decades and I believe all sane C++ code styles disallow multiple inheritance (possibly excepting pure abstract classes which are nothing but interfaces). I certainly haven't encountered any for a long time even in the OO-heavy code bases I've worked with.
One of the problems is that you might not use the target language at the equivalent level of abstraction. For example, C is a popular target language, but the C emitted may be very unidiomatic and nothing like human consumable code, it's not all that unusual that a language compiles all code to one big C function where the function calls in the language are jumps, which is a way to get around the limitations of the C calling conventions and stack.
The same thing applies to compilation to Javascript, the resulting code may use a tiny subset of the language.
I don't like the word transpiler, because there is nothing useful about the distinction (unless you count people using it to denigrate compilers that doesn't target traditional machine code).
I could see the case of using it as a name when the transformation is reversible, like you could probably turn Javascript back into Coffeescript.
I once worked at a bookmaker with millions of customers where they had extreme reliability demands during very popular events, since any bets that the punters couldn't place during live betting was lost money. They had one massive server with a big pipe and an identical hot spare in another location. It worked very well for them. That was a decade ago, you can get even bigger servers these days, there's a lot of room for scaling without needing to go beyond one machine.
The Old New Thing is very much engineering. Any contemporary engineers who don't think they have anything to learn from the experience of the past as recounted in the blog are doomed to repeat the same missteps.
And much as one would hope that Raymond Chen's blogging is holding up any important Microsoft initiatives, I very much doubt that it's much of a distraction for a megacorporation.
Also, you should be able to still search for Raymond Chen's blog process posts, but part of why he has nearly a blog post every work day for quite so many years is that he built up a huge queue, adds to the queue only during relatively free time, and has automated the posting of that queue. It's also seems to relate to why so many are multi-part deep dives. (This post also ends with a tease for the next post.) It was often probably only one root investigative journey related to a Windows support question investigation or user story writeup or documentation was needed to be written or some other TIL rabbit hole was found, but breaking it into multiple parts keeps each part easy to read individually and also keeps the queue full for weeks where things are much busier.
Any fan of determinism would need to tackle quantum physics and what seems like unavoidable randomness in it (and there are such theories, but they offer little hope of getting around the randomness from our point of view, since they hide the order from us). The typical example of a random phenomena in nature is radioactive decay. You can't predict when any given nucleus will decay, only the probability that it will happen (which gives the half-life).
They don't sell for the highest possible price, because sales would suffer, they try to sell for the price point that brings them most profit. Adding tariffs will change the point of maximum profit upwards, drastically so for low margin goods.
Companies sell for the highest price they can without losing more sales than it's worth, exactly as you say. I thought it was such common knowledge as not needing to be mentioned.
Adding tariffs means that you might have to lower your profit margins to remain competitive or that you will have to stop exporting to that nation completely, or start manufacturing in that nation. Which is the purpose of tariffs.
My work Ubuntu laptop has 40GB of RAM and and a very fast Nvme SSD, if it gets under memory pressure it slows to a crawl and is for all practical purposes frozen while swapping wildly for 15-20 minutes.
So no, my experience with swap isn't that it's invisible with SSD.
I don't know your exact situation, but be sure you're not mixing up "thrashing" with "using swap". Obviously, thrashing implies swap usage, but not the other way around.
I get it that the distinction is real but nobody using the machine cares at this point. It must not happen and if disabling swap removes it then people will disable swap.
I've experimented with no-swap and find the same thing happens. I think the issue is that linux can also evict executable pages (since it can just reload them from disk).
I've had good experience with linux's multi-generation LRU feature, specifically the /sys/kernel/mm/lru_gen/min_ttl_ms feature that triggers OOM-killer when the "working set of the last N ms doesn't fit in memory".
It's seldom invisible, but in my experience how visible it is depends on the size/modularity/performance/etc of what's being swapped and the underlying hardware.
On my 8gb M1 Mac, I can have a ton of tabs open and it'll swap with minimal slowdown. On the other hand, running a 4k external display and a small (4gb) llm is at best horrible and will sometimes require a hard reset.
I've seen similar with different combinations of software/hardware.
Linux being absolute dogshit if it’s under any sort of memory pressure is the reason, not swap or no swap. Modern systems would be much better off tweaking dirty bytes/ratios, but fundamentally the kernel needs to be dragged into the XXI century sometime.
It's kind of solved since kernel 6.1 with MGLRU, see above.
Dirty buffer should also be tuned (limited), absolutely. Default is 20% of RAM, (with 5 second writeback and 30 second expire intervals), which is COMPLETELY insane. I limit it to 64 MB max usually, with 1 second writeback and 3 second expire intervals.
How would you ensure that an LLM "gets" a puzzle mechanic and that reasonable attempts at it will be rewarded with progress, while not letting players sweet talk it into into disregarding the puzzle?
How about maintaining the state outside of the model's context for example in some SQLite database? The purpose of the language model would be as a language interface to a statically defined set of (SQL) commands/statements. And so on - there would be more problem's to be solved, of course, and sweet talking may always remain a possibility just as cheating is in any other game as well.
The current crop of LLMs are not able to consistently/logically update the state in the SQLite database based on player actions. They will update it when they are not supposed to, update it to the wrong value, and fail to update it entirely when they are supposed to.
I tried this. It sounds good on paper but the LLM will just "forget" to use it's tools. Either it will decline to query the database and just make stuff up, or it will decline to update the database when it should. The further along the game play gets the more out of sync the game word gets from the external state. I'm sure there is a clever solution but I never found it.
you're making the mistake to assume that leaving the structure of the communication and game play to the LLM is the only option. the LLM just is a tool serving a specific purpose in the game play. the LLM cannot forget to query if the query/state-management task is simply an imperative step in a loop. it's not left to the LLM to remember it.
reply