This will inevitably be used as ammunition against sideloading, but it’s really a lesson in supply chain trust.
When we move away from walled gardens (which I support), the burden of verifying the "chain of custody" shifts to the user. Installing an APK that auto-updates with root/system privileges is essentially giving a single developer the keys to your living room.
We need better intermediate trust models—like reproducible builds signed by a quorum of maintainers—rather than just "trust this GitHub release."
The value here isn't just indexing; it's narrative.
Reading the Linux kernel linearly is impossible because it’s not just code anymore—it’s 30 years of hardware quirks, scheduling theory, and architectural compromises solidified into C.
Tools like Elixir tell you where a symbol is defined. Tools like this attempt to answer why it's structured that way. As systems complexity outpaces human working memory, we need more "archaeological" tools that visualize the state machine, not just the text.
The "SQLite doesn't scale" argument is usually just premature optimization masquerading as architectural wisdom.
Unless you are actively hitting WAL contention limits (which is surprisingly hard to do on modern NVMe), the operational simplicity of a single binary beats the "scalability" of a distributed mess any day.
We’ve normalized a complexity tax where every side project "needs" a dedicated DB cluster and a Redis cache. Pocketbase proves that for 99% of CRUD apps, the bottleneck isn't the database—it's the network latency and the developer's time spent managing k8s manifests.
I’ve used PocketBase in production. We ran into DB issues because the admin page loaded all orders and that climbed over 5000. I didn’t think that was much for a read-only operation, but when 5 staff were loading it every 30 seconds, it occasionally got very slow: 10 to 30 second load times.
Faster Vultr server didn’t help. The recommendation was to redesign the admin page to do search on the server rather than in the client. But that wasn’t possible at the time.
I enjoyed writing on top of PocketBase and running it. The developer was very helpful - quick, useful responses. My brother did his wedding website with it. It’s great for small projects. For higher performance ones, you will need to test and shift your design.
That is not the case any more. The "users" show up in the shape and form of malicious AI crawling bots that don't honor your robots.txt nor apply any kind of self-throttling.
I have a personal blog set up on the cheapest digital ocean droplet and i went ahead with sqlite for it, there is not much traffic on it and i think something like sqlite is actually the best choice for such projects. I did some benchmarking with a rust cli tool, the name i don't recall right now, something like apache bench but simpler. I wouldn't have the same performance if i had mysql or postgres running on the same machine.
But you can create a dedicated DB cluster and Redis cache in AWS in 3 clicks. And then you have point in time recovery, replication, automatic failover, and guaranteed uptime. What happens when it's 3 AM and your Pocketbase server crashes?
Supabase uses Postgres. I don't see a strong reason to prefer Pocketbase to Supabase for commercial applications. Supabase has a generous free tier and you can scale or self-host.
Yes, you can add an enormous amount of complexity to your app in 3 clicks. Should you? The proverbial night crashes are, in my experience, often much better problem to have than the complexity and cost of AWS.
Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.
Do you only build stuff that performs financial operations? I'm not sure why sqlite being suboptimal for this one very specific use-case means that sqlite as a whole is a no-go for you.
No, not at all actually. But I had a lot of applications where at somepoint we needed to add storage of currency in the database. It became relevant for billing or other features. This without the app itself being financial in nature.
This and DATETIME. The workarounds for these are mostly fine if you’re just using SQLite as a key value store, but doing translations in SQL queries for these workarounds sounds atrocious.
90% of people aren't using "SQL" anyway. They are just doing basic CRUD operations on a data store with SQL syntax, usually abstracted through an ORM. The only reason they want a SQL database in the first place is for ACID.
If you find yourself caring about data types or actually writing a query, you should probably setup an actual database server.
Actually, with a good architecture, SQLite brings you very far. However, you need a solid architecture; otherwise, the journey ends very soon. So people with architectural wisdom can build great things with SQLite.
The ones who warn about it are often the ones who don't care about architecture and just plug stuff together.
The choice of MIT for a kernel feels like setting up the project to be cannibalized rather than contributed to.
We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix.
Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedded space, an MIT kernel is just free R&D for a vendor who will lock the bootloader anyway.
Not sure why am getting in the middle of this but I need to point out that you are not even correct for Linux.
Linux rather famously has avoided the GPL3 and is distributed under a modified GPL2. This license allows binary blob modules. We are all very familiar with this.
As a result, the kernel that matches your description above that ships in the highest volume is Linux by a massive margin. Can you run a fully open source Linux kernel on your Android phone? Probably not. You do not have the drivers. You may not pass the security checks.
Do companies like Broadcomm “collaborate” on Linux even in the PC or Mac space? Not really.
On the other side, companies that use FreeBSD do actually contribute a lot of code. This includes Netflix most famously but even Sony gives back.
The vast majority of vendors that use Linux embedded never contribute a single line of code (like 80% or more at least - maybe 98%). Very few of them even make the kernel code they use available. I worked in video surveillance where every video recorder and camera in the entire industry is Linux based at this point. Almost none of them distribute source code.
But even the story behind the GPL or not is wrong in the real world.
You get great industry players like Valve that contribute a lot of code. And guess what, a lot of that code is licensed permissively. And a lot of other companies continue to Mesa, Wayland, Xorg, pipewire, and other parts of the stack that are permissively licensed. The level of contribution has nothing to do with the GPL.
How about other important projects? There are more big companies contributing to LLVM/Clang (permissive) than there are to GCC (GPL).
In fact, the GPL often discourages collaboration. Apple is a great example of a company that will not contribute to even the GPL projects that they rely on. But they do contribute a fair bit of Open Source code permisssively. And they are not even one of the “good guys” in Open Source.
A few vendors have been stopped from shipping binary modules with Linux, notably those linking to certain symbols. Enough vendors have contributed enough to make Linux actually usable on the desktop with a wide range of off the shelf hardware and more and more are announcing day one compatibility or open source contributions. The same is hardly true for the BSDs.
It's obvious Sony is keeping certain drivers closed source while open sourcing other things, and why Nvidia decided to go with an open source driver. It's not hard to understand why, it could be some pressure or a modified GPL2.
Probably not, but possibly yes. Which is more than the cuck license guarantees. See postmarketOS and such, which would be impossible in a BSD world.
>The vast majority of vendors that use Linux embedded never contribute a single line of code
It doesn't matter. The point is just that they can be legally compelled to if needed. That is better than nothing.
>The level of contribution has nothing to do with the GPL.
None of this would be feasible if linux wasn't a platform where the drivers work. They wouldn't have worked on the linux userspace in the first place if it didn't have driver support: it wouldn't be a viable competitor to windows and the whole PC platform would probably be locked down anyways without a decent competitor. Permissive software is parasitic in this sense that it benefits from inter-operating in a copyleft environment but cooperates with attempts to lock down the market.
LLVM was made after GCC and is designed with a different architecture. It is apples and oranges.
Apple is a great example of a company that is flooding the world with locked-down devices. Everything they do is an obstacle to general purpose computing. What do they meaningfully commit to the public domain? Swift? Webkit? It is part of a strategy to improve their lock-in and ultimately make collaboration impossible.
I think GCC is the real shining example of a GPL success, it broke through a rut of high cost developer tooling in the 1990s and became the de facto compiler for UNIX and embedded BSPs (Board Support Packages) while training corporations on how to deal with all this.
But then LLVM showed up and showed it is no longer imperative to have a viral license to sustain corporate OSS. That might've not been possible without the land clearing GCC accomplished, but times are different now and corporations have a better understanding and relationship with OSS.
The GPL has enough area to opt out of contributing (i.e. services businesses or just stacking on immense complexity in a BSP so as to ensure vendor lockin) that it isn't a defining concern for most users.
Therefore I don't think Linux' success has much to do with GPL. It has been effective in the BSP space, but the main parts most people care about and associate with Linux could easily be MIT with no significant consequence on velocity and participation. In fact, a lot of the DRM code (graphics drivers) are dual-licensed thusly.
> But then LLVM showed up and showed it is no longer imperative to have a viral license
I am not sure I remember everything right, but as far as I remember Apple originally maintained a fork of gcc for its objective-c language and didn't provide clean patches upstream, instead it threw its weight behind LLVM the moment it became even remotely viable so it could avoid the issue entirely.
Also gcc didn't provide APIs for IDE integration early on, causing significant issues with attempts to implement features like refactoring support on top of it. People had the choice of either using llvm, half ass it with ctags or stick with plain text search and replace like RMS intended.
> Linux won specifically because the GPL forced the "greedy" actors to collaborate.
How do we know that? It seems to me that a greater factor in the success of Linux was the idealism and community. It was about freedom. Linux was the "Revolution OS" and the hacker community couldn't but fall in love with Linux and its community that embodied their ideals. They contributed to it and they founded new kinds of firms that (at least when they began) committed themselves to respect those principles.
I realise the memory of Linux's roots in hacker culture is fading away fast but I really do think this might have been the key factor in Linux's growth. It reached a critical mass that way.
I'm quite certain of the fact that this was more important anyway than the fact that, for instance, Linksys had to (eventually! they didn't at first) release the source code to their modifications to the Linux kernel to run on the WRT54G. I don't think things like that played much of a role at all.
Linksys were certainly kind enough to permit people to flash their own firmware to that router, and that helped grow Linux in that area. They even released a special WRT54GL edition to facilitate custom firmware. But they could just as easily have Tivoised it (something that the Linux licence does not forbid) and that would've been the end of the story.
We can't really prove it but I noticed a lot of people worked on BSD for a few years, got poached by Sun/NeXT/BSDI/NetApp, then mostly stopped contributing to open source. Meanwhile early Linux devs continued contributing to Linux for decades.
Kinda sad that the top comment on this really interesting project is complaining about the license, reiterating the trite conventional wisdom on this topic,which is based on basically two data points (Linux and BSD) (probably because any time someone tries something new, they get beaten down by people who complain that BSD and Linux already exist, but that's another topic).
This comment does not contribute to discussion of TFA: it's just license flamewar bait.
The authors almost certainly gave a bit of thought to their choice of license. The choice of license is a "business choice" that has to do with the author(s)' goals, and it is a choice best seen as intending to achieve those goals. Those goals can be very different from your own goals, and that's fine! There is no need to shame TFA for their choice of license, or implicitly for their goals as opposed to yours.
This comment is a tangential distraction, but it's not even correct. Linus Torvalds has specifically claimed that he wouldn't have created Linux at all if 386BSD was available at the time. But BSD was tied up in a lawsuit with USL, discouraging companies and individuals from use.
Not meaning to single you out specifically, but this entire discussion — all of this license gatekeeping is ridiculous. This is a very cool project, but if the license ruins it for you, there are zillions of open source GPL3 kernels.
I mean, this is not different from bitching about someone writing their custom kernel in C++ instead of Rust, or Zig. It’s not your project! Let people do their own thing! MIT is a perfectly fine license; maybe the lack of zealotry associated with it would even be a positive thing for whatever community might be built around this eventually, if the author is even interested in having other contributions.
That's 1980s-90s thinking. Nobody is making proprietary BSD forks any more and new kernels probably have no chance of reaching production anyway so worrying about proprietary forks is irrelevant.
Forget the interaction layer. The moat isn't UI, it's Reliability Engineering.
Right now, Manus and others are great at the 'Happy Path'. But when a 3-hour multi-step task hits a 503 error on step 47, does the agent gracefully recover, retry with backoff, or ask for specific human intervention? Or does it just hallucinate a success?
If you are building a B2C agent, differentiation comes from trust. If I can trust your agent to book a flight and actually verify the confirmation email (and handle the payment failure) without me babysitting it, that's the win.
Build an agent that handles failure like a distributed system (idempotency, checkpoints, dead letter queues), not like a chatbot.
Impressive numbers on paper, but looking at their site, this feels dangerously close to vaporware.
The bottleneck for inference right now isn't just raw FLOPS or even memory bandwidth—it's the compiler stack. The graveyard of AI hardware startups is filled with chips that beat NVIDIA on specs but couldn't run a standard PyTorch graph without segfaulting or requiring six months of manual kernel tuning.
Until I see a dev board and a working graph compiler that accepts ONNX out of the box, this is just a very expensive CGI render.
That seems like not much compared to the hundreds of billions of dollars US companies currently invest into their AI stack? OpenAI pays thousands of engineers and researchers full time.
It is. The problem is latency. All these fields are moving very fast, and so it doesn't sound bad spending 6 months tuning something, but in reality what is happening is that during those 6 months the guy who built the thing you're tuning has iterated 5 more times and what you started on 6 months ago is now much much better than what you got handed 6 months ago whilst simultaneously being much worse than what that person has in their hands today. If the field you're working in is relatively static, or your performance gap is large enough it makes sense. But in most fields the performance gap is large in absolutely terms but small in temporal terms. You could make something run 10x faster, but you can't build something that will run faster than what will be state of the art in 2 months.
This 100x. I used to work for one of those startups. You need something crazy like a 10x performance advantage to get people to switch from Nvidia to some here-today-gone-tomorrow startup with a custom compiler framework that requires field engineer support to get anything to run.
The outcome is that most of custom chips end up not being sold on the open market; instead their manufacturers run them themselves and sell LLM-as-a-service. E.g. Cerebras, Samba Nova, and you could count Google's TPUs there too.
I'm willing to pay the "performance tax" of the web stack/self-hosting if it means my design files aren't held hostage in a proprietary cloud silo.
Figma is fantastic software, but it has become a single point of failure for entire product orgs. If Penpot is "laggy" right now but gives me a docker-compose up guarantee that I own the pipeline, that's a trade-off I'll take.
Performance can be optimized eventually (it's code); closed-source licensing terms cannot be optimized by users (it's legal).
Exactly.
I'm a little interested to see if perhaps designer's eyes will continue to open to the power of licensing terms and control of their work with the whole AI conversation. The only designers i've heard say they care about open source are on the web side of design.
It really puts our current definition of "latency" into a painful perspective.
We have a machine running on 1970s hardware, a light-day away, that arguably maintains a more reliable command-response loop relative to its constraints than many modern microservices sitting in the same availability zone.
It’s a testament to engineering when "performance" meant physics and strict resource budgeting, not just throwing more vCPUs at an unoptimized Python loop. If Voyager had been built with today's "move fast and break things" mindset, it would have bricked itself at the heliopause pending a firmware update that required a stronger handshake.
I am certain if I had the estimated $4,000,000,000 it took to get Voyager 1 launched, I could get some microservices to function regardless of all scenarios.
The reality is, its only worth it to build to 99.9999% uptime for very specific missions... There is no take-backsies in space. Your company will survive a microservice outage.
> not just throwing more vCPUs at an unoptimized Python loop.
I've got the strong feeling that most of the Python frameworks, stacks and codes in operation of our generation will be the technical debts of the future computer world.
The fact that Python was meant primarily as both learning language (ABC legacy) and glue language (akin of scripting but not for building) make the Python based systems and solutions the duct tapes of the 21st century computing [2].
That sounds like a product manager's perspective, but I think the falls apart in deep space. When the feedback loop is 2 light-days long and hardware is irreplaceable. The original planned lifespan of Voyager was just 5 years.
You're breezing past the labor cost quite deftly. I'm reasonably sure that developing the Voyager probes required a few more people and hours than your average microservice.
Not that it would change your point, but as a separate matter I'm curious what the ratio of government employees to private contractors was back then when they were building the thing compared to now.
Spacecraft require more 9s of reliability than microservices. Their engineering processes are very different, even today. We still build new spacecraft today, even though we don’t launch them into interstellar space.
The domains are totally different and lead to different tradeoffs. An internal marketing data platform can justifiably be optimised for iteration speed and quick scalability over availability.
To see this just as a hosting switch misses the bigger picture. This is the logical infrastructure conclusion of Zig's 'Zero Dependency' philosophy.
Zig spent years removing dependencies on the system C compiler (zig cc), removing dependencies on libc, and is currently working to remove the dependency on LLVM (the self-hosted backend).
GitHub was just another dependency.
For a project obsessed with reproducibility and toolchain sovereignty, relying on a single proprietary platform (and its changing ToS/AI policies) was a massive architectural liability. They aren't just moving repos; they are eliminating 'Platform Risk' the same way they eliminated 'Linker Risk'.
