peter_d_sherman

>"Because there will always be unaligned AI.

If you have access to a model’s weights, it is trivially easy to change its alignment.

And even if there would be no strong open weight models, if there are multiple AI developers, there will be commercial incentives for some of them to make models with different alignment and reduced safeguards. Such models are useful, because they give you capabilities. So the only world in which a particular type of alignment would be “stable” would be one in which there is only one company that provides advanced AI models. Now, those large AI companies with valuations in the trillions are not trying to become monopolies? Right?

A pluralistic world with many different belief systems and ways of living requires there to be many different AI models, models that are not by default going to agree with each other.

This requires us to build a society where we don’t generally trust AI agents

, and where we have strong, layered, and diverse cybersecurity. Just like

democratic societies are loud and messy and built around elaborate sets of checks and balances.

We need to regularly be reminded that we should trust the intentions of neither people nor AI systems.

Efforts to ban unaligned AI models or make sure that all models align the same way are therefore actively harmful to building resilient individuals and societies."

A series of excellent points!

>"Does this mean that I think people should not work on alignment? No. Lots of good technical work is motivated by AI alignment. Reinforcement learning from human feedback, for example. And models need post-training to be useful. We need more of this, but

it would be more honest to call it controllability research."

I too, am agreed that AI model aligners should continue to work on AI model alignment. That research is, or can be, useful...

But, I too, am agreed that people in that field -- could be more honest about their work...

>"What I do think is that people who work on AI safety should stop focusing on alignment or thinking that it could somehow be “solved” (which would seem to imply “solving” ethics, a major red flag as discussed above) and start thinking harder about pluralistic futures where there’s not a single superintelligence, but a whole bunch of them and they can’t get along."

Again, another excellent point! (This blog article "fires on all cylinders" doesn't it? :-))

>"This might make for terrible wars or very good TV, depending on what tools we give them and safeguards we implement."

You're "batting a million" here, Dr. Togelius! An unbelievable amount of prescience in your mind!

(And me, while I have distaste for the average war, I have tremendous taste for very good TV -- so if both cannot be rendered mutually exclusive (as ideally they would be!), then at least the very good TV aspect might be highly desirable! :-) )

Anyway, great article!

Related:

Who guards the guardians? https://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%...

Who verifies the verifiers?

Who aligns the aligners?

>"Our guest kernel starts from tinyconfig, not a standard distribution configuration. We leave out hardware subsystems a microVM does not need, including Bluetooth, wireless, USB, and display drivers. Your coding agent definitely doesn’t need a Nintendo Switch controller."

Nice! (And no, your coding agent definitely doesn't need a Nintendo Switch controller, or probably 99.99% of the other drivers!)

Related:

https://z49x2vmq.github.io/2020/12/24/linux-tiny-qemu/

https://weeraman.com/building-a-tiny-linux-kernel/

https://blinry.org/tiny-linux/

Looks absolutely stellar!

Another step forward for local AI / local LLM inferencing on (very!) resource-constrained consumer GPU hardware!

>"Time-domain codecs (such as ADPCM) need significantly higher bitrates for this quality. Subband codecs, such as MP2, have much worse quality at comparable bitrates, and more “modern” transform codecs, such as MP3, usually need at least an 80–100 MHz CPU. For this GBA demo, no existing codec would fit the bill.

So Aikku93 not only wrote a decoder in ARM assembly, but also created a whole new codec: The Ultra Low Complexity Codec (ULC).

ULC is a transform codec and somewhat similar to MP3. ULC transforms slices of PCM data into the frequency domain. Like MP3, it uses the Modified Discrete Cosine Transform (MDCT) to do so. But unlike MP3, it does not split the signal into multiple bands (ULC's MDCT is “full-band”). Where MP3 uses classic entropy encoding (Huffman specifically), ULC does… not. Instead, transformed coefficients are stored with a very simple nibble-based syntax.

In short: ULC is what MP3 could have been. The same core idea, but without the cruft around it."

Nice!

This would make a great audio compressor / decompressor to run on older computers, on older operating systems, on older more resource-constrained hardware (not just the N64) !

Anyway, really nice!

Related:

https://en.wikipedia.org/wiki/Modified_discrete_cosine_trans...

Related:

https://wccftech.com/former-intel-ceo-patrick-gelsinger-back...

Related:

Gibson's Law:

"For every PhD. there is an equal-and-opposite PhD.":

https://en.wikipedia.org/wiki/Gibson%27s_law

>"That's when I realised my ISP was hijacking my DNS queries and returning a tampered IP address.

[...]

Now here's the catch. DNS resolution doesn't happen over a single connection. Your resolver might have to talk to multiple nameservers to figure out an IP address, and these queries are traditionally sent over plaintext DNS, usually UDP. Which means, you guessed it, your ISP can snoop on or even tamper with your DNS traffic."

This article raises several excellent points.

Basically, unencrypted DNS requests are not private.

Even encrypted DNS, once it gets to the DNS Server wherever that is, is no longer private to the owner of that DNS server, because it is unencrypted there... it may go nowhere from there, but then again, there could be logging and/or monitoring...

And DNS servers that you think don't belong to your upstream ISP -- can be proxied/rerouted by your upstream ISP...

If those points are understood by consumers, then an average person can clearly see why there is such a market (and that's the magic word, "market") for privacy solutions, i.e., encrypted VPN's, encrypted 3rd-party DNS, IP source address anonymization, etc., etc., here in the U.S. ...

In other words, a savvy privacy company or companies could sell to all U.S. Internet customers regardless of who their upstream ISP is, or what their upstream ISP promises in terms of privacy, if (and it's a big if!) they truly understand these issues and could explain them from the ground up, one-to-one, to all such potential customers...

Yes, there are a lot of VPN and other such companies, and prior customers already (not to mention free alternatives, such as Tor (but I still have questions about the exact quality of privacy Tor actually provides given browser fingerprinting and other related technologies), but that market is still segmented, has a relatively low bar for entry, and is still "up-for-grabs" for new small companies (i.e., no need to invest billions in a datacenter of GB300's to get your first AI model out...)...

Anyway, great article.

I never considered some of these issues (or their implications!) before reading it!

Looks beautiful!

The SGI Indigo (https://en.wikipedia.org/wiki/SGI_Indigo) was quite the advanced piece of hardware back in the day (1991), where it could be thought of as the graphics "spiritual successor" to the color NeXTstation (1990) https://en.wikipedia.org/wiki/NeXTstation, which could in turn be thought about as the graphics "spiritual successor" to the original Amiga 1000 in 1985 (https://en.wikipedia.org/wiki/Amiga_1000).

(Of course, later in computer history, discrete graphics cards (the ancestor of the AI accelerator card) would grow in scope and power, eventually surpassing graphics capabilities that were specifically tied to, or bound to, a specific manufacturer or computer type -- but the SGI Indigo was a revolutionary milestone for its place and time in this history! They are still collectible today, and I highly applaud the author(s) of this project for bringing back (on FPGA with Verilog!) this quintessential piece of computer / computer graphics history!)

Anyway, looks beautiful!

>Lovely long-form comment, a joy to read. The way you explain the concept of "handles" as an abstraction useful in a whole class of situations.

Well thank you very much! I appreciate the kind sentiment!

> Any problem in computer science can be solved with another level of indirection.

Indeed! I forgot to include this part when writing, it was "at the tip of my consciousness" but I couldn't recall that exact text exactly, so I didn't include it -- but you nailed it!:

>https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...

>An entire operating system conceptualized as a hierarchy of handles.

It's quite the concept isn't it!

Incidentally, if you look at the Assembly compiler output of any "Object-Oriented" programming language (i.e., C++, ObjectPascal, etc.), you will notice that it is generating what looks like normal Assembly functions for non-Object-Oriented programming languages (C, Pascal, etc.), except that each function is getting passed an additional first parameter (typically as EAX on 32-bit x86 systems, RAX on 64-bit x86 systems), and that first parameter is actually a pointer to the "Object" in memory (pointer to a data structure that comprises the "Object" in memory -- since Assembler has no concept of higher-level programming language Objects!), but it's function is to allow a flat traditional function to operate on the data (and call associated related "object" functions (via another level of pointer indirection)) -- well, it's the same principle as a Handle (that of "Indirection": https://en.wikipedia.org/wiki/Indirection) in effect!

>It's about encapsulation, and designing the interface between objects.

Indeed!

>How handles are like functions, makes me think. A function is a form of indirection, and it can be seen as a handle or interface with defined types of inputs and outputs.

Exactly!

>And the useful of handles/proxies in testing. Yes, it solves the same question as "dependency injection" but in a more functional style.

You get "dependency injection" virtually for free!

>You pass in a handle with well-defined types of vaues, which can be treated the same way by functions whether the handle operates with a local test database or the actual production one. It's being able to have multiple implementations, or instances, with the same interface.

Yes! And (added bonus!) it decouples the handle using program (client) from the handle serving program (server!). That is, the code is not as strongly linked "bind/bound together" as code using raw pointers, and can be separated across boundaries (across processes on a single machine, across the internet on multiple machines) if the data is marshalled (fancy term for if the data of the variable which contains the integer value for the Handle is moved from point A to point B, wherever point A and B are, i.e., HTTP(S) request + JSON or XML or BSON or other structured data exchange format...)

Anyway, thank you again for your kind sentiments!

Completely agreed!

The most popular program of all time which used the concept of "Handles are the better pointers" -- is/was the Microsoft Windows series of operating systems (from a little company called Microsoft, in Seattle).

You have have heard of it (or them!)

You see, in that OS, individual windows (as GUI elements and "Operating System Objects") were not pointers, but Handles!

Every other OS-controlled object (Bitmaps, Brushes, Fonts, Device Contexts, etc.) were also Handles!

You see, Application Programmers (for normal applications, not Ring 0 device drivers) -- were never given direct pointer access to OS internal data structures!

Instead the OS handed out Handles for different OS-managed objects to application code that asked for them, allocated and managed the memory they used during their lifetime, and disposed of the memory so allocated when the application using them had completed or terminated.

Unix/Linux is similar -- except that the application programmer typically gets what's called a "File Handle" (because "everything's a file" under Unix/Linux...)

But generally speaking (and yes, there are exceptions like mmap() on Unix/Linux and ring-0 drivers on Windows) the application programmer never manages the memory allocation or disposal themselves, they never use direct pointers for these objects, they go through an OS proxy to that OS structure, that proxy is called a "handle", and it moves the proper responsibility for memory allocation/deallocation of the resource to the OS, away from the programmer.

Compare and contrast this with the use of handles (as proxies) and the concept of "Encapsulation" (from Object Oriented programming, but equally applicable here) in codebases where you have a central Senior developer who writes the central code in a language like C or C++, full of pointers, complex data structures, complex dynamic memory allocation/deallocation, etc., and you have regular developers who write code via the use of Handles around that central code, i.e., that central code does not expose pointers or direct memory -- instead it exposes an API or functions where regular programmers request handles, and subsequently pass the handles with additional API calls to the central codebase to gain functionality for whatever object or objects are represented by the handle.

(You can also compare this to obtaining a token/cookie from a web API, then passing that token/cookie on subsequent requests with different additional parameters to different endpoints on a single website's API to gain different functions related to the use of the back end object or objects that that token/cookie is related to...)

Also, I should point out that while replacing pointers with handles in code may make a programming a little bit slower, it also allows the handle allocation code to save/update a list of allocations. Hybrid code could replace pointer operations with handle allocation in a test/debug codebase, then replace it again with native pointer operations in a release codebase (faster, once all the bugs are worked out). A handle allocator is a powerful tool to check for memory allocation errors in code if it's programmed correctly... Allocate the same handle twice -- have your handle allocation code can check for that, and raise an immediate exception! Forget to free it at the end of use? Raise an exception for that! It's a great way to find bugs in pointer code!

Anyway, great article!

Related:

https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...

https://en.wikipedia.org/wiki/Pointer_(computer_programming)

A series of excellent points!

Hopefully future healthcare policy makers (both in the public and private sector) will read them, and get some good advice from them...

>"Training more doctors would supposedly compromise patient safety because it would mean lowering the bar for admissions and straining existing staff that need to train them. Even if you could admit and train them all, supplying enough doctors to meet market demand would cause a wage collapse breaking the ROI of med school expenses."

There seems to be a vicious circle in place between too much medical regulation requiring a corresponding amount of long and expensive education, and the high cost of medical education in general...

Which one is cause and which one is effect I do not know...

It would seem to the casual observer, that both aspects might feed into one another...

One thing I do know is that doctors from foreign countries, especially if they are third-world countries, typically have had to pay less, sometimes a whole lot less, for their medical education, compared to their U.S. counterparts...

Is that medical education as good as a U.S. medical education? Well, I don't know! Maybe it is in some cases, maybe it isn't in others...

What is known though is that foreign medical educations frequently cost less, sometimes a whole lot less -- than their U.S. counterparts...

Is hiring foreign doctors the solution or part of the solution?

I don't know that either, but I do know that there are a lot of foreign doctors (and previously foreign doctors before becoming U.S. Citizens) in the U.S., and certainly many more abroad...

Is AI the solution, or part of the solution?

It's definitely a wildcard with promise at this point; it'll be interesting to see where it goes in the future...

Anyway, you make some excellent points!

Hopefully future policy makers will read them and act on them...

>You can already buy shares in a nations economy - it is called owning currency.

An interesting point! Yes, that is definitely one way that currency could be looked at...

>The big difference from stocks is that most countries issue new shares (dollars, etc) to keep the price stable (indirectly via careful control of interest rates).

Agreed -- but if we were really to analyze things, scrutinize the way things really work at the highest degree of resolution, then we would have to observe that:

a) There are multiple countries/currencies in the world.

b) That each country's/currency's inflation rate is different than all of the other countries/currencies.

c) If each country's/currency's inflation rate is different, this means that each countries's issuance of new shares (and control of interest rates) -- their financial policies, are, by comparison, either more effective, on par, or less effective than those of other countries used for comparison...

Phrased another way:

All countries do not control the rate of inflation of their currencies equally.

Phrased another way:

Some nations are better at controlling their currency's rate of inflation than other nations.

True or not true?

>I am simplifying terribly

As am I! :-)

>but just as shares represent a fraction of a company, cash represents a share of a nation’s economy.

Again, an interesting point!

And yes, I could agree with that!

Some excellent points!

>There's a lot wrong with health insurance in the US but this problem is largely on providers, not payers.

How would you fix it?

>"In 2022, a Pulitzer-winning Wall Street Journal investigation analyzed over 31,000 financial disclosures from 12,000 senior government employees, revealing that nearly a quarter of federal officials traded stock in industries their agencies regulated."

Ya know, on the one hand, I wonder how many federal officials own nVidia stock and stock of other AI companies...

But then again, on the other, I wonder how many nVidia employees (and those of other AI companies!) own government T-bills (and other government backed securities!) in their 401K or other investment accounts!

You know, everybody in large corporations and governments owning shares in other large corporations and governments -- adds a whole new level of meaning to "stakeholder capitalism"... :-)

(In the far future, there'll probably be small foreign governments which become their own ticker symbol -- and get publicly traded on various stock exchanges! :-) You know, like: "Would you like to buy a share in Denmark (DNMK) or perhaps Norway (NRWY)? I hear they're very competitive with Apple (AAPL) right now! Great price to earnings (PE) ratio!" :-) )

Prevention Vs. Cure...

(aka Proactive Vs. Reactive)

((aka Present Responsibility Vs. Future Response))

"An ounce of Prevention is worth a pound of Cure" (as the old expression goes...)

Observation: Most health insurance policies today, whether they are government or private corporation, national or regional, are based on the idea of paying for medical/health problems AFTER the onset of the health problem...

Prevention, preventative health, preventative medicine, and preventative programs -- would not only do a lot to preempt future health problems, but it would also save a ton of money (a ton of taxpayer money if the health insurance is a government sponsored one), as the above article so eloquently makes clear!

Observation: Some insurance policies do include some preventative health aspects -- but as medicine is complex and there are always new discoveries, there is always another step up, another higher level in what could be delivered...

In other words, these could always be improved...

"An ounce of Prevention is worth a pound of Cure" (as the article implicitly suggests...)

Anyway, great article!

Excellent article!

Heck, not just an excellent article, an exceptional one!

This is why I read HN -- to find articles like this one!

The basic problem:

Everybody loves Software! Software, specifically having a huge breadth and variety for a given platform is the key to that platform's success! (Just ask Bill Gates of Microsoft that, about Windows!) Well a lot of Open Source software is on GitHub, but one problem is (or rather was!) that it needed to get built for a whole bunch of platforms... Simple right? Well, not so much for the average user who is not a programmer when there are numerous types of CPU (x86, ARM, RISC-V, etc., etc.), numerous OS platforms, numerous compilers and compiler versions, and (usually) other dependencies on specific versions of other Open Source software packages...

So who could solve this chaotic "wild west" of exponential build combinations?

Well, historically, GNU autotools (aclocal, autoconf, autoheader, automake, autoreconf, autoscan, gnu m4, libtool, etc., which created files such as: aclocal.m4, config.h, config.h.in, config.log, config.status, configure, Makefile, Makefile.in, etc.) tried to solve this problem, and for the most part did so -- but usually only for users who were familiar with using Unix/Linux command-line tools and usually only for GNU compilers, and build processes which had dependencies on other projects or libraries could break rather spectacularly if the exact correct version of those projects or libraries that the base software was dependent on was not known, or not selected correctly.

What was needed was something more generic, and yet more precise.

Enter Eelco Dolstra, and his Ph.D. thesis "The Purely Functional Software Deployment Model": https://edolstra.github.io/pubs/phd-thesis.pdf

Which is the basis for the Nix functional programming language, NixPkgs and NixOS.

Basically, all problems in software deployment (i.e., configuring and building software correctly from source) could be solved if there was the following:

Immutability in Storage: Once a software component is built, it is stored in a centralized location (the Nix Store, typically /nix/store) and marked as strictly read-only. Components are never modified in place.

Purity of the Build Process: Build actions are treated as mathematical functions. A build process is strictly isolated and hermetic—it is stripped of access to external environment variables or network resources, ensuring that the exact same inputs will always produce the exact same cryptographic output.

Well, turns out Eelco Dolstra and Nix / NixOS were right!

Why? Because now there are over 140,000 Open Source software packages in NixPkgs, i.e., installable by the Nix Package Manager. That's more than any other Linux package collection. And the breadth of combinations of CPU's, Platforms, OS'es, etc., far surpasses the build options of any other Linux distro's package collection!

But that's the next problem, and that's the problem this article so brilliantly addresses -- which is, if all of that software ecosystem, all of those build scripts are ultimately tied to Nix language, and the Nix language is hard to understand / hard to modify for newcomers to it, then how to unbind that entire software ecosystem from the Nix language?

And the answer (or at least one answer!) is what this article author suggests, which is "hey, let's convert the Nix language to Typescript"!

And this is (one great!) solution to the following problem:

>"Anyone who wants to explore the store-model space from a different direction, a new language, a new evaluator, a new editor experience, must then start from zero packages. This is the graveyard where other reimplementations or forks of Nix go to die."

Well not anymore!

Anyway, a truly brilliant article!

>"The IO parameter is even more powerful, even if it is newer. It is well worth the breaking changes required to bring it about (even if I skipped the 0.15.0 -> 0.16.0 transition). In Zig, every function that interacts with the underlying operating system (with caveats) requires an "IO" parameter. This provides the context for input, output, and everything else.

Porting Zig to new operating systems is mostly just porting IO."

Nice!

(In Software Engineering, I think with this change, Zig nailed Separation Of Concerns: (https://en.wikipedia.org/wiki/Separation_of_concerns) aka modularity/modular design, at least with respect to handling the asymmetries of different OS's I/O APIs/syscalls - rather nicely!)

Anyway, very interesting article!

Related:

https://ziglang.org/download/0.16.0/release-notes.html#IO-as...

https://www.ziglang.in/learn/standard-library/io-interface/

Grokipedia is certainly one example of what could be done -- but it might not be the penultimate nor ultimate possibility of what might be expressed by other motivated individuals in the future, in this space...

>Wikipedia's Cleanup of AI-Generated Content

What I think is interesting is that in this day and age of AI with free Open Source web server software, unbelievably cheap data storage, and very inexpensive Internet hosting prices,

basically anyone can run their own version of Wikipedia

So, do specific Wikipedia articles lean too far to the left or too far to the right for your tastes?

Do specific Wikipedia articles lean too liberal or too conservative for you?

Do specific Wikipedia articles lean too pro-Democrat or pro-Republican for you?

Maybe you're just a Scientist or Physicist or Electrical Engineer and you don't like the censorship of "Free Energy" articles, er, I mean "Overunity", er, I mean "Cold Fusion", er, I mean "Low Energy Neutron Reactions" (LENR), er, I mean, "Free energy can't possibly exist, and we know this to be absolutely true!"...

Maybe you're a Programmer or Sysadmin, and you have your own opinions on the "systemd is not good" vs. "systemd is good" debate!

Maybe you're a Mathematician and you feel that some of the Wikipedia Math articles are either too complex for anyone to understand them effectively -- or conversely, too simple, and omit important facts!

Heck, maybe you think Chunky is a Soup, but then again, maybe you think it "eats like a meal!" and the associated Wikipedia page doesn't accurately reflect this belief!

Maybe you think New Shimmer is desert topping! But then again, maybe you think it's a floor wax! But you believe that the associated Wikipedia page doesn't present these facts accurately or fairly, in a non-biased way!

Well, there's a simple solution to all of these problems, all of these dilemmas, and more! Which is:

Basically run your own version of Wikipedia!

AI can be used en masse, to clean up the content of any Wikipedia web pages you don't like!

Simply fork Wikipedia, grab copies of its data (which is or should be public domain), write a prompt to look for and change (according to your own political, relgious, moral, or just-plain-common-sense beliefs!) all of the Wikipedia web pages that you feel are not "the truth, the whole truth, and nothing but the truth, so help [them/me/you/they] G-d!", and then host the thing yourself!

It's not impossible in this AI age!

Note that I am not suggesting that everyone do this; I am merely alluding to the fact that with AI, this task is now within the realm of possibility to be accomplished, whereas previously, it would have been significantly difficult...

Anyway, great article!

(And for the record -- Wikipedia is usually about 98%-99% correct on most hard STEM subjects, and an excellent starting point for research, so I'm not saying all of the above to knock Wikipedia in any way! We should all remember that Wikipedia was revolutionary for its time, and remains an excellent starting point for STEM research!)

In the training phase, penalizing models not just for wrong answers, but

also for excessive length in the (CoT) thinking trace

seems to be the recipe, or at least part of the training recipe, for training a model to "think" less (and thus output less CoT tokens and thus operate faster) at approximately the same accuracy as the same model, previously trained without penalizing excessive length wrong answers in the thinking trace...

Anyway, well done BottleCap AI!

There is something interesting here...

It's not so much related to Enron or what a historic corporation did right or what a historic corporation did wrong, although those aspects are interesting too...

What's interesting is the use of an AI, an LLM, to create a "knowledge map" (in this case a Wiki, but it could have taken other forms) of a whole bunch of disjoint, separate, and apparently (at first glance, to the naked eye of a casual observer) disparate information from different emails at different dates and times to different parties outside of the company, the only common thread being that they were sent by employees of the same company, and for the AI/LLM to be able to extract facts and a knowledge graph ("who knew what, when") again, in the form of a Wiki (but could have been in another format), and this allows "making sense of", some "higher level viewpoint of" (at least to some better degree than all of the emails alone), again, in this case, in the form of a Wiki.

Now, this set of ideas could have some application far beyond Enron, far beyond investigations, far beyond what Enron historically did right or Enron historically did wrong...

For example, large companies and other organizations could create Wikis based on public facts in email corpuses for onboarding new employees. Not just for email interactions with outside companies (customers, suppliers, etc.) but for how different systems, different business processes used by the company work, or are supposed to work. Sort of like new employee manuals where there are entries like "if this fails, then do this...", or here's our documentation which shows that we're ISO-9000 compliant, etc. etc.

Point is, the amount of uses for something like this in a corporate setting is theoretically unlimited.

Of course, there might be issues as to what information different types of employees could read about, that is, larger corporations may wish to set access controls to different types of information, but there's no reason why an AI/LLM couldn't perform this function (with human oversight!) as well. Each of those could be ironed-out on an per-company, per-case, ad-hoc basis...

But again, the point is, the amount of potential uses for something like this in a corporate setting is theoretically unlimited...

Anyway, great article, and great idea!

>"The lethal puzzle is a generator, and any rule can ask for it. The ad rule is one caller. While we were testing it live on iPhone, a second caller fired on camera: PersonalMarginBreakTrait. Once you’re 10% past your high score, it rolls on every deal, and 20% of the time it asks for the same lethal puzzle:

Our record was 1,304, so its line was 1,434. At 3,356 points it rolled, and the game dealt a five-long bar, a five-tall bar and a zigzag. The game’s own record of that deal names this rule as the caller, shows algorithm 9 both requested and used, and labels all three pieces 致死题, lethal puzzle."

I love it!

From a linguistic "this one takes the cake in terms of strange terminology" strange terminology, this one takes the cake!

I could see this becoming a meme on the Internet... just like "pwned" (misspelling of "owned") was a long time ago...

I almost want to write a sitcom episode around it... something like "you've been playing this game too long... so now you get a "lethal puzzle!"..." :-). Classic! :-)

Anyway, very interesting article!

>"What is Rouler?

Rouler is split tunnelling for Windows. You choose which network interface each app uses: a privacy VPN for your browser, a work tunnel for work apps, and your normal connection for everything else. They all run at the same time."

Sounds like a great idea!

Related:

https://ualinkconsortium.org/

Related:

Looped Transformer:

https://sebastianraschka.com/llm-architecture-gallery/looped...

Nanbeige4.1-3B: A Small General Model that Reasons, Aligns, and Acts:

https://arxiv.org/abs/2607.22083

Nanbeige-4.2-3B

https://huggingface.co/Nanbeige

Ouro:

https://ouro-llm.github.io/

Related: https://layerbase.com/pricing

Related chart (since a picture is worth a thousand words!):

https://www.lei.chat/posts/mlir-codegen-dialects-for-machine...

(Note the high-D Tensor abstraction of a program or compute kernel being reduced over several steps to low-D vector / scalar execution... it's nothing short of magical, in my opinion!)

>"On a single GPU, this model delivers up to 5x higher throughput for agentic tasks compared to other open models in its size category.

[Scatter plot comparing Artificial Analysis Intelligence Index scores and output speed for open-weight models with 100K input tokens. Nemotron 3.5 Super VL exceeds 600 output tokens per second; the chart marks a 5x speed comparison with Inkling Small.]

Figure 1. Nemotron 3.5 Super VL delivers over 600 TPS on Artificial Analysis Intelligence Index agentic tasks on the Baseten endpoint"

This ~5x improvement is definitely a step forward!

Related:

https://component-model.bytecodealliance.org/language-suppor...

https://opencs.aalto.fi/en/courses/programming-languages/par...

https://github.com/vivshaw/neurastheniacc

https://github.com/WebAssembly/wabt