peter_d_sherman

>"Virtually all processors today have data parallel instructions (sometimes called SIMD) that can check several values at once.

[...]

The binary search checks one value at a time. However, recent processors can load and check more than one value at once. They have excellent memory-level parllelism. This suggest that instead of a binary search, we might want to try a quaternary search..."

First of all, brilliant observations! (Overall, a great article too!)

Yes, today's processors indeed have a parallelism which was unconceived of at the time the original Mathematicians, then-to-be Computer Scientists, conceived of Binary Search...

Now I myself wonder if these ideas might be extended to GPU's, that is, if the massively parallel execution capability of GPU's could be extended to search for data like Binary Search does, and what such an appropriately parallelized algorithm/data structure would look like... keep in mind, if we consider an updateable data structure, then that means that parts of it may need to be appropriately locked at the same time that multiple searches and updates are occurring simultaneously... so what data structure/algorithm would be the most efficient for a massively parallel scenario like that?

Anyway, great article and brilliant observations!

>"Rebuilding Takes Years. Always.

[...]

Money was never the constraint. Knowledge was.

[...]

Now map that onto software. A junior developer needs three to five years to become a competent mid-level engineer. Five to eight years to become senior. Ten or more to become a principal or architect. That timeline can’t be compressed by throwing money at it. It can’t be compressed by AI either."

Well said!

>"Single, reusable primitives play a disproportionately large aesthetic and practical role in mathematics, engineering, and even biology. Widely known classical examples include the NAND gate (and its dual, Peirce Arrow, logical NOR) for Boolean 0/1 logic [2, 12], the operational amplifier [13] for positive and negative feedback processes, and, more recently, the rectified linear unit (ReLU) ”ramp” activation function [14] in deep learning [15]. We also mention Wolfram’s single axiom [16], K,S combinators from combinatory logic [17, 18], Interaction Combinators [19], and fuzzy versions of the Sheffer stroke [20]. Other wellknown examples are one-instruction set computers (OISC), e.g. SUBLEQ [21], Conway’s FRACTRAN [22] and the Rule 110 cellular automaton [16, 23]."

>"If AI makes every engineer 50% more productive, you don't get 50% more output. You get 50% more pull requests. 50% more documentation. 50% more design proposals. And someone, somewhere, still has to review all of it.

When two or three early adopters start generating more PRs than before, the team absorbs it. No big deal.

When everyone does it, review becomes the constraint.

The bottleneck doesn't vanish. It moves upstream, to the parts of the job that are irreducibly human: deciding what to build, defining "done," understanding the domain, making judgment calls about risk.

I've written about this pattern before:

the work didn't disappear, it moved.

What's new here is that it moved specifically into verification - and most teams haven't consciously staffed or structured for that yet.

[...]

The question isn't "how do we produce more code?" anymore. The question is "how do we verify more code?" And I don't think most teams have a real answer to that yet."

Excellent article!

It's a great question... how do we verify AI produced code? We could use AI to do that too, but then:

Who verifies the verifier?

Related:

Quis custodiet ipsos custodes? (Alternatively known as: "Who watches the watchmen?" / "Who oversees the overseers?" / "Who manages the managers?" / "Who guards the guardians?" / "Who reviews the reviewers?", etc., etc.):

https://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%...

IMHO: Of all of the videos showing Pi's relationship with the Arithmetic-Geometric Mean (AGM), this is the best one.

Related:

Gauss–Legendre algorithm:

https://en.wikipedia.org/wiki/Gauss%E2%80%93Legendre_algorit...

Arithmetic–Geometric Mean (AGM)

https://en.wikipedia.org/wiki/Arithmetic%E2%80%93geometric_m...

Chudnovsky algorithm

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

Landen's transformation

https://en.wikipedia.org/wiki/Landen%27s_transformation

Binary splitting:

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

Brilliant idea!

Heck, a brilliant potential bootstrapped-from-virtually-nothing-except-a-cell-phone business idea!

(Comedy writing mode ON):

SNL's Stefon character: "This one has it all... Waffle House, FEMA, breakfast foods, federal emergencies, waffles, emergency preparedness, eggs, teleportation, bacon, black helicopters, hash browns, angry men in combat fatigues talking to God over 2-way radios, George Carlin, grits, syrup for the grits, toast, military communications, orange juice, armageddon/end-of-the-world apocalypse themes, milk, coffee and other breakfast items... all for a very reasonable price!"

:-)

(Comedy writing mode OFF)

What a brilliant idea!

Split a "it needs to run in a datacenter because its hardware requirements are so large" AI/LLM across multiple people who each want shared access to that particular model.

Sort of like the Real Estate equivalent of subletting, or splitting a larger space into smaller spaces and subletting each one...

Or, like the Web Host equivalent of splitting a single server into multiple virtual machines for shared hosting by multiple other parties, or what-have-you...

I could definitely see marketplaces similar to this, popping up in the future!

It seems like it should make AI cheaper for everyone... that is, "democratize AI"... in a "more/better/faster/cheaper" way than AI has been democratized to date...

Anyway, it's a brilliant idea!

Wishing you a lot of luck with this endeavor!

>"ASGs are more complex and concise than ASTs

because they may contain shared subterms (also known as "common subexpressions").[1]

Abstract semantic graphs are often used as an intermediate representation by compilers to store the results of performing common subexpression elimination upon abstract syntax trees."

Related (Transpiler IR Related):

Intermediate Representations:

https://cs.lmu.edu/~ray/notes/ir/

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

QBE Intermediate Language:

https://c9x.me/compile/

https://c9x.me/compile/doc/il.html

Can Large Language Models Understand Intermediate Representations in Compilers?:

https://arxiv.org/abs/2502.06854

There's an interesting set of ideas here!

If we look at the history of programming languages, we see the idea of Templating occuring over and over again, in different contexts, i.e., C's macros, C++ Templates, embedding PHP code snippets into an otherwise mostly HTML file, etc., etc.

Templating can involve aspects of meta-code (code about the code), interpretation proxying (which engine/compiler/system/parser/program/subsystem/? is responsible for interpreting a given section of text), etc., etc.

Here we see this idea as another level of proxied/layered abstraction/indirection, in this case between an AI/LLM and the underlying source code...

Is this a good idea?

Will all code be written like this, using this pattern or a similar one, in the future?

I for one don't know (it's too early to tell!) but one thing is for sure, and that's that this new "layer" certainly contains an interesting set of ideas!

I will definitely be watching to see more about how this pattern plays out in future software development...

Full text:

https://github.com/righttoprivacyact/bill/blob/main/bill/rig...

>"The quacking that catches my ear is when something develops a dependency graph: your package depends on a package that depends on a package, and now you need resolution algorithms, lockfiles, integrity verification, and some way to answer “what am I actually running and how did it get here?”

Several tools that started as plugin systems, CI runners, and chart templating tools have quietly grown transitive dependency trees. Now they walk like a package manager, quack like a package manager, and have all the problems that npm and Cargo and Bundler have spent years learning to manage, though most of them haven’t caught up on the solutions."

https://edolstra.github.io/pubs/phd-thesis.pdf

Very interesting!

Yes, in this day and age, I could definitely see web pages being harder to crawl by search engines (and SEO companies and other users of automated web crawling technologies (AI agents?)) than they were in the early days of the Internet due to many possible causes -- many of which you've excellently described!

In other words, there's more to be aware of for anyone writing a search engine (or search-engine-like piece of software -- SEO, AI Agent, etc., etc.) than there was in the early days of the Internet, where everything was straight unencrypted http and most URLs were easily accessible without having to jump through additional hoops...

Which leads me to wonder... on the one hand, a website owner may not want bots and other automated software agents spidering their site (we have ROBOTS.TXT for this), but on the flip side, most business owners DO want publicity and easy accessibility for sales and marketing purposes, thus, they'd never want to issue a 403 (or other error code) for any public-facing product webpage...

Thus there may be a market for testing public facing business/product websites against faulty "I can't give you that web page for whatever reason" error codes from a wide variety of clients, from a wide variety of locations around the world.

That market is related to the market for testing if a website is up and functioning properly (the "uptime market"), again, from a wide variety of locations around the world, using a wide variety of browsers...

So, a very interesting post!

Also (for future historians!) compare all of the restrictive factors which may prevent access to a public-facing web page today Vs. Tim Berners-Lee original vision for the web, which was basically to let scientists (and other academic types!) SHARE their data PUBLICLY with one another!

(Things have changed... a bit! :-) )

Anyway, a very interesting post, and a very interesting article -- for both present and future Search Engine programmers!

>"But an approach that’s immediately and broadly applicable today—and for which we’re releasing several new products—is based on what we call

computation-augmented generation, or CAG.

The key idea of CAG is to inject in real time capabilities from our foundation tool into the stream of content that LLMs generate. In traditional retrieval-augmented generation, or RAG, one is injecting content that has been retrieved from existing documents.

CAG is like an infinite extension of RAG

, in which an infinite amount of content can be generated on the fly—using computation—to feed to an LLM."

We welcome CAG -- to the list of LLM-related technologies!

My favorite quote from the article:

"Don't shoot the messenger. The person reporting the bug is not your enemy. The bug is."

Here is what Grok says about the above (I asked it to explain it better):

Grok:

"⟨T⟩0: ZFC (The Material) — Zermelo–Fraenkel set theory with the axiom of choice (the standard foundation for most modern mathematics). Called "The Material" and metaphorically "the box that contains the idea of a box," highlighting how ZFC provides the basic "stuff" (sets) out of which everything else is built. Without this, "you aren’t even playing the game."

⟨T⟩1: Topology (The Stage) — Introduces the primitive notion of "nearness" or continuity without any rigid measurement (no distances or angles yet). Famously, topology is "rubber-sheet geometry," where continuous deformations are allowed, so a donut and a coffee mug are equivalent (both have one hole/handle). Singularities/infinities (e.g., zero-point in physics or the point at infinity in projective geometry) can exist naturally here without causing foundational issues.

⟨T⟩2: Geometry (The Ruler) — Builds on topology by adding concrete measurements (distances, angles, metrics). It's topology "forced to commit" to specifics.

⟨T⟩3: Algebra (The Syntax) — Focuses on symmetries and structures (groups, rings, fields, etc.) that geometry permits. It's more abstract and rule-based ("the ledger" tracking allowed operations).

⟨T⟩4: Analysis (The Measure) — Deals with limits, continuity, change, integration/differentiation, etc. ("measuring the vibration of a string"). It's powerful for dynamics but "blind" to deeper structural issues in the underlying topology or sets.

(Or, phrased another way, it's one set of possibilities for a "Math/Mathematics Stack" (AKA "Abstraction Hierarchy", "Math Abstraction Hierarchy") built level by level, on top of the foundation of Logic...)

This is a highly interesting comment from user "thoughtfullyd4c9a86b93" on the above site:

>"My two cents worth — Logic is fundamental. Most of mathematics does not treat infinities nor singularities as first class citizens. Yet, there are a lot of problem classes in which you can actually reason with a set that includes those limits. My preference is a strict axiomatic hierarchy where you can not blend “levels”. Each level is a gatekeeper for the next tier.

The idea that mathematics is a language of its own does not work until you completely disambiguate mathematics in your language of choice — and logic is a language that facilitates complete understanding.

* ⟨T⟩0: ZFC (The Material). The box that contains the idea of a box. If you aren’t starting here, you aren’t even playing the game.

* ⟨T⟩1: Topology (The Stage). This defines “nearness” before you own a ruler. It’s the rubber floor where a donut is a coffee cup—and where singularities (like the zero-point or the absolute) are perfectly admissible inhabitants.

* ⟨T⟩2: Geometry (The Ruler). Adding distance and angles. It’s just Topology after it’s been forced to commit to a specific measurement.

* ⟨T⟩3: Algebra (The Syntax). The ledger for people who trust the ruler more than the stage. It tracks the symmetries the geometry allows.

* ⟨T⟩4: Analysis (The Measure). Measuring the vibration of a string to prove the violin is real. Great for change, but “blind” to the structural admissibility of the stage itself."

This looks like a reasonably good page (there possibly are better ones) for general AI chatbots, rate limits and sign-in requirements:

https://fmhy.net/ai

(Comedy writing mode ON: )

"We need to flatten the curve..."

(Comedy writing mode OFF: )

You know, to re-quote the powers-that-be and the mainstream news media...

What, no takers?

You know, "flatten the curve... of population increase?" -- what, still not funny?

Hey, I'm just re-quoting what other people said... (a whole lot of people, incidentally!) but in the context of the article, above!

What, still no takers?

You people have no sense of (dark, very dark, let's be completely honest about that!) humor!

:-)

>"The abstraction tower

Here’s the part that makes me laugh, darkly.

I saw someone on LinkedIn recently — early twenties, a few years into their career — lamenting that with AI they “didn’t really know what was going on anymore.” And I thought: mate, you were already so far up the abstraction chain you didn’t even realise you were teetering on top of a wobbly Jenga tower.

They’re writing TypeScript that compiles to JavaScript that runs in a V8 engine written in C++ that’s making system calls to an OS kernel that’s scheduling threads across cores they’ve never thought about, hitting RAM through a memory controller with caching layers they couldn’t diagram, all while npm pulls in 400 packages they’ve never read a line of.

But sure. AI is the moment they lost track of what’s happening.

The abstraction ship sailed decades ago. We just didn’t notice because each layer arrived gradually enough that we could pretend we still understood the whole stack.

AI is just the layer that made the pretence impossible to maintain."

Absolutely brilliant writing!

Heck -- absolutely brilliant communicating! (Which is really what great writing is all about!)

You definitely get it!

Some other people here on HN do too, yours truly included in that bunch...

Anyway, stellar writing!

Related:

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

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

https://en.wikipedia.org/wiki/Abstraction_(computer_science)

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

https://ecommons.cornell.edu/entities/publication/3e2850f6-c...

>Hey Peter, Thanks! I really appreciate the thoughtful feedback and your time.

I stand by what I said -- it is a really good idea!

>It is a challenge as startups transition all the time in different ways - funding rounds, IPOs or the dreaded deadpool - and I'm trying to figure out the best way to represent it. At this time, I'm using a combination of manually vetting,

I think that it's noble that you'd take it upon yourself to do this task manually, but this task may turn out to be too time-consuming and unsustainable into the future -- you might wish to consider outsourcing it and/or automating it with AI and/or automating it via trusted users who are entrusted to perform those updates... or of course, you could just continue to do it yourself...

>to soliciting public feedback through "edit this profile" button and showcasing the latest state. Rather than deleting entities that are no longer startups, I tag them with statuses like Public, Acquired, Shut Down, etc., and surface that on the profile page.

I think that's a good idea! More information, more transparency, more historical auditability, more information in general!

>Long-term, I'd like this to behave more like a "historical record" of startups over time (dare say wikpedia for startups but presented differently?), not just a snapshot of "current startups". That way acquisitions, failures, and IPOs become first-class signals instead of reasons to delete data.

It sounds like you are well on your way! I fully support that! "Wikipedia for Startups" sounds great, and if I needed to give a VC an elevator pitch of what you do in 60 seconds, or heck, 10 seconds or less, I'd phrase it exactly that way... "Wikipedia for Startups" (sounds great and communicates quickly!) or "Wikipedia for Startups but presented differently" (as you said!) or maybe "Wikipedia for Startups but presented with our own custom enhancements!" (sounds even better and would make the party on the other end ever more curious about it!).

But yes, looks great in general, I saw you're taking job listings (great idea, will help you monetize for the long haul!), and I think you're on a great track! (and of course, the world does very much need a "Wikipedia for Startups", however it is presented! :-) )

(Also, don't forget that Joel Spolsky made million$ when one of his interns added job search to his blog and Stack Overflow -- so the job search is a great way of monetizing and sustaining your vision, long term!)

So, wishing you a lot of luck!

It's brilliant, brilliant, brilliant, I say!

>"But NixOS isn't the only declarative distro out there. In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. Specifically Guile Scheme..."

I'd be curious if a list exists of all declarative Linux distros out there, along with the configuration language (Nix, Scheme, etc.)

I'd also be curious as to how easy it would be to convert Scheme to the Nix language or vice-versa, in other words, it seems to me that there might be a "parent language" (for lack of a better term) out there for all lisplike and functional programming language (a subset of Haskell, F#, or some other functional programming language perhaps) that sort of might act as an intermediary conversion step (again, for lack of a better term!) between one functional or lisplike programming language and another...

Probably unrelated (but maybe somewhat related!) -- consider Pandoc... Pandoc is a Haskell program that basically uses a document tree structure to convert between one type of document format and another... maybe in terms of programming languages you'd call that an AST, an Abstract Syntax Tree... so maybe there's some kind of simplified AST (or something like that) out there that works as the base tree for all functional and lisp-like programming language (yes, lisp/lisplikes sort of preserve its/their own tree; their own AST -- via their intrinsic data structure, and that would seem to be true about functional programming languages too... so what is the base tree/AST of all of these, that all languages in this family can "map on to" (for lack of better terminology), that could be used (with AI / LLM's) as an "Intermediary Language" or "Intermediary Data Structure" (choose your terminology) to allow easily converting between one and the other?

Anyway, if we had that or something like that, then Nix configurations could (in theory) be easily converted to Guix, and vice-versa, automatically, as could any other Linux configured by a functional and/or lisplike language...

That, and I found the article very interesting!

I may have to try Guix in the future!

>I’m six months behind on rent, just managed to buy time after my first eviction notice, and I’m trying to get back into building without constantly worrying about when the next one shows up.

Why not create a broker website between people who are getting eviction notices and Lawyers who specifically help people who are getting eviction notices?

That is, use what you are...

Or rather (phrased another way),

use the set of circumstances you are in, to turn around the set of circumstances that you're in.

It may sound meta, but if you individually are having a problem -- then so are a ton of other people as well!

If solving that problem has value to you, then such a solution is worth money.

If many people are also having that problem, then solutions to that problem are also worth money to them!

Sure, a legal solution, for example, finding an appropriate Lawyer to extend the point in time before eviction for say, 1-2 months (or whatever can be done) may be a suboptimal partial solution (in an ideal world, you'd like your rent to be free forever, as would everyone else), but the thing is,

even suboptimal partial solutions are worth money, if only a little bit of money...

Phrased another way,

there's money to be made by acting as a broker between people with eviction problems and the subset of Lawyers who specialize in that field, who could potentially ameliorate that problem if only a tiny amount, if only a little bit...

There's also money to be made in books and online reports... "What to do if you get an eviction notice".

Which such a book or report might not be worth the price of rent (obviously if someone had the rent money they'd pay it, problem solved), that information may be worth $19.95, or something in that ballpark...

Scaled across thousands of people with the same problem -- and we're looking at some decent money!

It probably won't make you rich or anything... but (and this is going to sound "evil" -- but it is not intentionally so!) it might make you enough money to pay your rent! :-)

use what you are

use the set of circumstances you are in, to turn around the set of circumstances that you're in.

Education, Knowledge, and Experience are everything...

Money, if it exists, if it exists at all, exists relative to, as an effect of these things...

Do you know everything possible about every single Landlord/Tenant Law and every single possible way to resolve an eviction notice?

If not... then I'd suggest that you are in one hell of an opportunity to learn everything you can about the matter!

Expertise (in any subject matter) translates to being sought, to being paid (sometimes very highly!) by others in return for advice, in return for knowledge, in return for communicated experience...

Money will naturally follow you with this learning once you have it, and once you monetize it -- although this will probably not happen today or tomorrow -- but it will in the future, if you can see the opportunity and capture it!

use what you are

use the set of circumstances you are in, to turn around the set of circumstances that you're in

Wishing you well in this... experience!

(You know, for lack of a better term! :-) )

>This started as a personal project because I wanted a clean, searchable dataset of startups across regions without jumping between multiple sources or dealing with noise I didn't want :).

I love this idea!

Something like that really needs to be done, and you've stepped up to the plate to begin that journey of putting all of that together!

A list of ALL startups, in one place, would really be great!

One question/caveat though -- how do you determine / how would you determine if a startup is no longer in startup mode?

That is, if the startup has become a big business, if the startup has been acquired, if the startup has failed, etc., etc.?

I guess (if the correct data wasn't present or unavailable or hard to parse, etc.) you could simply take startups off the last after a fixed time period, like maybe 12 months, 24 months, <?> months, ?.

Or, maybe add a retrieval date and source...

Two extra fields for your database... the date when it was spidered/sourced/parsed/found/uploaded/etc, and the source URL (or URL's...).

Then you could keep all of the data for all time... just let your users sort/filter on that retrieval date, for "freshness" of data, relative to their needs...

Anyway, looks great so far!

Great work!

>I am working on a high-performance game that runs over ssh.

By 'ssh', you mean 'ssh' (library/program + protocol + encryption + decryption) on top of TCP/IP, on top of the Internet, right?

OK, I'm not against it... but you do understand that there are all kinds of ways for that to slow things down, right?

Your issues may (or may not!) include such things as:

o Nagle's algorithm AKA buffering AKA packets not being sent until N bytes (where N > 1) ready to send, as other posters have suggested;

o Slower encryption/decryption on older hardware (if users with older hardware is a target market, and if the added loss in speed makes an impact in gameplay, depending on the game, this may or may not be the case...)

o The fact that TCP/IP (as opposed to UDP / Datagrams / "Raw" sockets) imposes a connection-oriented abstraction, requiring additional round trips of ACK ("I got the packet") RESEND ("I didn't get the packet") on top of the connectionless architecture that is the Internet (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...), which adds additonal latency, so, for example if a rural user in Australia experiences a 350ms delay for a raw packet to get to a U.S. server (or vice versa), then TCP/IP might make this 700ms or more, depending on the quality of the connection!

o The speed of the game limited to both the bandwidth and latency of the slowest user (if a multi-player game, and if the game must not update until that user "moves"... again, game architecture will determine this, and it wouldn't be applicable to all games...)

Now, you could use UDP, as other posters have suggested, but then you must manually manage connections and encryption...

That may be the right choice for some types programmers, some types of games/applications -- but equal-and-oppositely it may be the wrong choice for others...

Anyway, wishing you well with your game development!

I haven't used SSH (at least, not in a debug capacity), so I'm not sure what SSH debugging options exist -- but it would be nice if SSH had a full logging debug mode, which would explain exactly WHY it chose to send any given packet that it did along with related helpful information, such as latency/time/other metrics, etc., if it doesn't have this/these feature(s) already...

>"This program generates images from text prompts [...] using the [data from] FLUX.2-klein-4B [...] and is implemented entirely in C, with zero external dependencies beyond the C standard library."

You had me at image generation!

Pure C with zero external dependencies -- is just an extra added bonus...

No, actually, pure C with zero external dependencies -- is quite awesome in its own right!

Well done!

I absolutely love it!

(Now, I would have preferred a Lattice ICE40 FPGA as opposed to the Xilinx Spartan II XC2S100 FPGA, simply because the ICE40 toolchain is entirely open source (https://prjicestorm.readthedocs.io/en/latest/) but that's a very minor (less than 1%) extremely small "nitpick" -- on what should be praised and lauded as some truly great work!)

Anyway, to repeat, I absolutely love it!

Upvoted and favorited!

Well done!

Random Idea: A Completely Open-Source Banking App...

Consider an Open-Source Web Browser (Chromium, FireFox, ?, ???, or any open-source browser from: https://github.com/nerdyslacker/desktop-web-browsers).

OK.

We know the following:

A) That most Banks have web pages / websites which can be accessed via one or more of the above web browsers (AKA "Online Banking"), where the provided functionality is exactly the same, or very close to the functionality provided by stand-alone banking Apps

B) That the source code for any open-source web browser is available, and can be downloaded (A self-evident truth!)

From which the following understanding can be derived:

C) The security for the transactions (user authentication, authorization, etc., etc.) is NOT provided on the client side (the user's computer or smartphone) by an obfuscated "binary black box" piece of software where source code is not provided, but rather on the server side (the Bank's side!)

(Oh sure, Web Browsers provide encryption to prevent the middle segment of the communication path, the Internet, from listening in, but the encryption libraries of open-source web browsers are also typically themselves open-source, thus easily transferred to / imported into the source code bases / software component stack -- of other Apps!)

Well, if we know A), B), and C), then we also understand that a truly Open-Source Banking App, giving exactly the same security guarantees that an Open-Source Web Browser does today, is possible!

Such an app, if it were to exist, due to its open-source nature, would not be bound by artificial constraints, such as the absence or presence of an underlying rooted Smartphone, or not...

Also, in theory such an App, were it to exist, could be ran on very minimal, possibly more secure (than your average bloated Smartphone) alternative hardware...

Also, if you think about it... Bitcoin and other cryptocurrency apps -- are fundamentally that App (!) -- just that they use the Blockchain, and not a Bank, as the back-end! :-)

You know, you have a payment-provider App. It could have any number of back-ends to it... Bank, Blockchain, ?, ???

You tell me... :-)

>"This wasn’t a fully transparent codebase, though. Like many production appliances, a large portion of the Python logic was shipped only as compiled .pyc files."

Observation: One of the great virtues of Python is that typically when someone runs a Python program, they are running a Python interpreter on transparent Python source code files, which means that typically, the person that runs a Python program has the entirety of the source code of that program!

But that's not the case here!

.pyc, aka "pre-compiled, pre-tokenized, pre-digested" aka "obfuscated" python -- one of the roots of this problem -- is both a blessing and a curse!

It's a blessing because it allows Python code to have different interpretation/compilation/"digestion" stages cached -- which allows the Python code to run faster -- a very definite blessing!

But it's also (equal-and-oppositely!) -- a curse!

It's a curse because as the author of this article noted above, it allows Python codebases to be obfuscated -- in whole or in parts!

Of course, this is equally true of any compiled language -- for example with C code, one typically runs the compiled binaries, and compiled binaries are obfuscated/non-transparent by their nature. And that's equally true of any compiled language. So this is nothing new!

Now, I am not a Python expert. But maybe there's a Python interpreter switch which says 'do not run any pre-digested cached/obfuscated code in .pyc directories, and stop the run and emit an error message if any are encountered'.

I know there's a Python switch to prevent the compilation of source code into .pyc directories. Of course, the problem with this approach is that code typically runs slower...

So, what's the solution? Well, pre-created (downloaded) .pyc directories where the corresponding Python source code is not provided are sort of like the equivalent of "binary blobs" aka "binary black boxes" that ship with proprietary software.

Of course, some software publishers that do not believe in Open-source / transparent software might argue that such binary blobs protect their intellectual property... and if there's a huge amount of capital investment necessary to produce a piece of software, then such arguments are not 100% entirely wrong...

Getting back to Python (or more broadly, any interpreted language that has the same pre-compilation/obfuscation capability), what I'd love to see is a runtime switch, maybe we'd call it something like '-t' or '-transparent' or something like that, where if passed to the interpreter prior to running a program, then if it encounters a .pyc (or equivalent, for whatever format that language uses, call it "pre-tokenized", "pre-parsed", "pre-compiled" or whatever), then it immediately stops execution, and reports an error where the exact line and line number, the exact place where the code in the last good source file which called it, is reported, exactly to the end-user, and then execution completely stops!

This would allow easy discovery of such "black box" / "binary blob" non-transparent dependencies!

(Note to Future Self: Put this feature in any future interpreters you write... :-) )

We know, minimally, from Perplexity's list above, that there exist multiple alternative DRAM manufacturers other than Micron, Samsung and SK Hynix, that have completed at least some of the barriers of entry to the high-end DRAM market, and possibly many...

We also know that the world is full of capital -- as you suggest.

That capital is continually looking for investment opportunities, and DRAM is a huge, huge market...

When capital invests in markets, any barriers to entry are moved, if not outright displaced (i.e., OpenAI, $1 billion, etc.).

Point is, we don't know what the future will hold...

I think it's a good bet that cheaper DRAM, DDR5 and otherwise, will be coming down the pike soon, once production catches up, once supply outpaces demand...