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, ?, ???
>"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... :-) )
(Note that I have not researched each of these companies individually... There may be errors in the above list (some may be DRAM resellers, some may be defunct, etc., etc.))
Coke and Pepsi dominate the worldwide drink market, but due to the immense size of the market, there are always up-and-coming competitors.
Go to your local superstore, supermarket, or your local convenience store.
You'll find Coke and Pepsi, lots of it, but you'll also find no-name drinks and sodas from drink companies that are not as well established yet or well known.
That those exist is a good thing, at least for consumers, at least for those that consume, because the root of all consumer prosperity brought on by capitalism (global trade = capitalism, regardless of the names of countries involved) comes from the relentless competition brought on by two or more companies, ideally as many as possible...
We would not have the super high performing desktop computers we have today if it were not for the historic early competition between AMD and Intel (later entered by other CPU manufacturers), and we would not have choice if it were not for competition.
Getting back to DRAM manufacturers, The first three do dominate 95+% of the market as of 2026.
But there might be some interesting up-and-coming smaller companies to watch...
Let's remember that OpenAI came from basically nowhere -- to give Google a run for its money -- as did Google with Microsoft's behemoth 20+ years ago...
What new DRAM manufacturer might be the next up-and-coming DRAM manufacturer in the space?
Well, we don't as-of-yet know... but the space is an interesting one to watch, to be sure!
But you are correct!
The first three do currently dominate 95+% of the market as of 2026...
Isn't there higher barriers to entry than OpenAI and soda? They were able to compete with "commodity" hardware. A DRAM manufacturer would need expensive machines from ASML, right?
I'm not forced to drink Coke or Pepsi if I go to a bar. Only if I specifically want a cola I very likely get whatever cola they got (likely either Coke or Pepsi). If you want to use a computer, it will have DRAM, and you'll end up with one of the DRAM hardware manufacturers.
> Let's remember that OpenAI came from basically nowhere -- to give Google a run for its money -- as did Google with Microsoft's behemoth 20+ years ago...
Yeah, but the capital behind it certainly did not:
> OpenAI was initially founded as a nonprofit organization by Altman, Greg Brockman, Elon Musk, Jessica Livingston, Peter Thiel, Microsoft, Amazon Web Services, Infosys, and YC Research. When OpenAI launched in 2015, it had raised pledges for $1 billion. [1]
Altman was well connected, with rich friends. People like Thiel and Musk. Under the guise of a non-profit they eventually pulled a rug to make OpenAI for-profit.
The barrier of entry for hardware design is also just plain different than software. There was a good talk on that recently on 39c3.
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...
Seems more likely OpenAI or one of the hyperscalers would continue vertical expansion into chips but likely only supply themselves--possibly making proprietary variants only they could use anyway
Seems to be the case with CPUs although I know that's a bit different since they're contracting with existing fabs
>"Later this year, Point2 will begin manufacturing the chips behind a 1.6-terabit-per-second cable consisting of eight slender polymer waveguides, each capable of carrying 448 gigabits per second using two frequencies, 90 gigahertz and 225 GHz. At each end of the waveguide are plug-in modules that turn electronic bits into modulated radio waves and back again. AttoTude is planning essentially the same thing, but at terahertz frequencies and with a different kind of svelte, flexible cable.
Both companies say their technologies can easily outdo copper in reach—spanning 10 to 20 meters without significant loss"
This is absolutely fascinating! For the longest time, I thought that optical fibers were the future, but waveguides (of whatever material appropriate) at whatever frequenc(y|ies) appropriate could give optical fibers a run (get it, a "run"? :-) ) for the money!
If we think about it, both fiber and copper cables are both very specific cases of a more broader
waveguide (first) principle...
That is, in theory you could make something that looks like a wire or cable out of any material(s) -- and if the material(s) and apertures and frequencies are correct, then you've created a transmission of path for data from point A to point B...
So, kudos to Point2, AttoTude (and other future companies!) that go down this technological tract! You're increasing both human knowledge (and data rates!) -- which could never be a bad thing!
This may just become my next most favorite project on GitHub!
For anyone who would create their own OS, or just experiment with other OS'es, this could be a godsend!
The set of ideas which gives rise to this tool are brilliant, and while I haven't reviewed all of the code for potential security implications (as I would want to if I were deploying it to a production server in a business environment) -- it looks very well thought out at first glance!
Extra kudos for having a flake.nix (for us Nix users!)
And extra extra kudos for having Alpine, Nix, ReactOS, TinyCore and OpenBSD as downloadable OS choices!
In the future, I'd love to see Windows XP, Windows 2000, and Windows NT too (assuming that Microsoft would permit that!) -- but that would just be the icing on the cake!
Short review: There's potentially something for everyone here! (Well, any OS person! Could Minix 3 be added in the future? :-) )
Long review: Will definitely have to watch this project in the future, to see where it goes!
My first reaction was: Fuck! Terrible timing!! I just spent the last few days (during some time off from work) manually setting up macOS and Windows qemu VMs on my homelab running Proxmox, just to see if I could do it. And navigating all the janky, old tutorials, forums full of "try this" junk, hitting roadblock after roadblock (ProTip: macOS versions > Monterey will NOT run on Ivy Bridge processors in a virtualized environment) and trying to filter out and dodge AI garbage advice, was a real slog. Why didn't I see this article the first time it made the rounds on HN???
My second reaction was in line with yours. This is awesome. Bookmarked already. +1 for the suggestion of doing more ancient Windows versions.
I installed Sequoia but it’s painfully slow on a 4 core 3ghz something or other. I previously did the one after high sierra and it’s reasonably snappy, but APFS outdated for my situation
>"We also have a contract with AMD to get MI350X on MLPerf for Llama 405B training."
Anything to help AMD (and potentially other GPU/NPU/IPU etc. chip makers) catch up with NVidia/CUDA is potentially worth money, potentially worth a lot of money, potentially worth up to Billion$...
Why?
If we have
a) Market worth Billion$
and
b) A competitive race in that Market...
then
c) We have VALUE in anything (product, service, ?, ???) that helps any given participant capture more of that market than their competitors...
(AMD (and the other lesser known GPU/NPU/IPU etc. chip vendors) are currently lagging behind NVidia's CUDA AI market dominance -- so anything that helps the others advance in this area should, generally speaking, be beneficial for all technology users in general, and be potentially profitable (if the correct deals could be struck!) by those that have the skills to do such assisting...)
Anyway, wishing you well in your endeavors, Tinygrad!
This is by far the absolute best "how things go from a high-level (AI/LLM/Inference/Python/JAX/etc.) to low-level (TPU equivalent of assembly language instructions)" article that I've read to date!
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... :-)
reply