I think the idea is good if it could actually curb bot traffic that currently plagues the Internet.
However, a lot of recent bot traffic are sophisticated scrappers called "LLM's." You can tell claude to "research X from this www.example.com" and will automatically scrape it and summarize it, something that a LLM is perfect for. Gemini tends to share links instead, presumably because most of Google's revenue comes from ads served on those websites, so if it completely killed the traffic to those websites it would just make less money. Incidentally, I wonder if Claude/Gemini use an search engine-like "index" of all websites or it refuses to cache anything to always fetch "fresh" data.
If this is employed, I don't think the web is only going to be gatekept to Google devices. I think it will also be gatekept to Google's AI's.
Google would be able to display a captcha that no LLM could defeat, and then just let its own LLM pass through.
The same could be said about its other bots, such as the web crawler. Google's bot could crawl webpages that no other crawler would ever be able to simply because it has free pass to captcha-gated GETs. Although the same could be true already today.
Their product page is full of info about how this works with "agentic" cruft. They're still permitting your regular old scrapers and bots for as long as they like you. Hope you're not thinking of running an independent system instead of a large cloud platform!
The only problem I have with it is GTK-style bulkiness. I feel like every open source software is developed for 4k quad-monitors in mind, or tablets. Everything is thicker and taller than it needs to be.
I hated that Linux has all these commands you had to go through, then I installed Windows 11 and tutorials were telling me run all these commands to fix it. I figure I'd just use Linux at that point.
> I hated that Linux has all these commands you had to go through
Was this still your experience though? I am using Fedora on GNOME and I rarely have to use the terminal. I like to use it but if you don't want to, you don't have to. There is a graphical installer, settings panel, software center, file manager, disk utility software, etc.
To me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amount of time you spend dealing with packaging, distribution, etc., is small and you don't care about file sizes.
But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install necessary.
The same thing on Linux? Impossible. There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained you need to ship the entire OS. Now your file size is huge. I can't use Python, because now Windows users need to have Python or I have to ship an interpreter.
The only plausible alternative is something like Java. Now you have a single .jar file that runs on any system. But then Oracle changed the license, and JavaFX is no longer part of Java (Swing still is).
Honestly, I just want to display a menubar with keyboard shortcuts. Why can't there be a menubar VM or something that gives me access to a menubar on all OS's without having to deal with all of this. We are already shipping the entire browser with Electron. That is stupid. The way it should work is users install a something like Flash but for desktop apps and every app just uses that platform.
It's probably easier to ship a DOS game than a desktop app because everyone who wants to run a DOS game will just have a DOS emulator installed.
This will run on Windows, Linux, MacOS, and Tcl's starkit/starpack system makes it easy to generate a single executable file for each OS that can just be copied over and run without any installation needed.
What I mean is that on Windows you can just ship an 100kb .exe and forget about it and it's still going to work 20 years later.
On Linux that doesn't happen. First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed. Second of all, even if you do ship the source code, you're going to be forced to maintain it. If you made an app in GTK 1 (which looks beautiful, by the way, compared to modern GTK), people won't be able to just install it because GTK 1 is so old that it's no longer in the repositories.
An app made in Java 8 runs in the modern VM. An app made for Windows 95 still runs on modern Windows.
It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
I'm not defending this but there was (or has been) enough political motivation and intentionality in GNU/Linux systems to make binary compatibility a hassle. People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing.
Binary compatibility means closed source has a chance to grow in an ecosystem. It requires "responsible" developers to put more effort into designing APIs and keeping them alive. It adds complexity that requires a more stable set of long-term developers; in contrast, the constant churn in FOSS requires lower barriers for contributions. With stable APIs/ABIs you have to live with decade-long mistakes. You cannot "just fix it" in a next major bump.
> First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed.
That's so very not true.
Most Linux distros allows for custom repositories. So you can just setup the build infrastructure on your side and then have the users include your repos on their side. No need to open source code and users have painless update notifications.
> It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
Lots of users have never seen the source code of their software, they just get the binary package. The pressure you're talking about is imaginary.
This is downright misinformation. There are no 100kb Windows programs that work for 20 years. Every single program on Windows ships half of the system libraries again, just for use by itself. Microsoft couldn't be bothered to version their libc at the beginning ffs.
WINE is often somewhat jokingly called a more stable platform for Windows programs than Windows is but there's truth there.
One thing I miss from using Windows is that the desktop didn't just freeze completely if you ran out of RAM.
At first I thought that maybe Linux doesn't have ways to give priority to the desktop environment (a.k.a. "graphical shell") which is why running out of RAM means your cursor starts lagging, clicking on things stops working, etc.
But maybe Linux is just bad at that in general and a single process eating too much RAM can simply bring the whole system to a halt as it tries to move and compress RAM to a pagefile on an HDD (not SSD).
Every time it happens to me I just find it so incredible. Here I am with a PC with a multiple cores, multiple processors, and a single process eating all the RAM can bottleneck ALL of them at once? Am I misunderstanding something? Shouldn't it, ideally, work in such way that so long as one processor is free, the system can process mouse input and render the cursor and do all the desktop stuff no matter what I/O is happening in the background?
Since it's Linux maybe it's just my DE/distro (Cinnamon/Mint). Maybe it does allocations under the assumption there will always be a few free bytes in RAM available, so it halts if RAM runs out while some other DE wouldn't. But even then you'd think there would be a way to just reserve "premium" memory for critical processes so they never become unresponsive.
I wonder if other people have the same experience as me. This part of Linux just always felt fundamentally poor for me.
This issue is much worse if you don't have swap. What happens, I think, is that as memory allocated by processes grows to fill the available RAM, it starts to push out memory that doesn't technically need to be in RAM, like cached file pages. Which accounts for some of the slowdown, until it reaches the code itself, which is 'just' a memory mapped file. So eventually most of the code that is actively trying to run is being pushed out of RAM and must be loaded in as it executes, slowing everything to a crawl and generally creating a death spiral. If you have swap the kernel can decide to put other pages onto disk and keep the more important stuff in memory. Or you can run something like early-oom which stops things from getting to that point in the first place (albeit in a somewhat brute-force manner).
Dealing with low-memory situations elegantly is pretty hard: firstly Linux uses memory overcommit by default, in part because the semantics of fork imply very large memory commitments which are almost never realised, and in part because a lot of software does the same because it's the default. Secondly, managing allocation failures is often tricky and ill-tests, and often requires co-ordination between different systems. The DE could, though, in principle, put running applications in a container which would prevent them from using above a certain amount of memory, but the results are similar to early-oom in that the result of reaching the limit is almost certainly the termination of the process using the most memory.
Yes, but the problem, I feel, is the priority of what gets pushed out to RAM on Linux.
You could split the processes into 2 categories:
1: applications that are doing tasks the user wants.
2: OS processes that the user needs to interact with in order to terminate applications.
There is an argument for applications taking priority: the user wants to do a task, if you move application out of RAM, the task is going to take longer.
But to me OS processes, including the graphical shell (taskbar, windowing system, etc.), should have priority: if an application hangs on I/O, the user NEEDS to be able to use the taskbar in order to terminate the application, otherwise they're going to have to wait who knows how long for the application to finish its task (or just hard reset the computer).
I don't know anything about how Linux handles memory, but the impression I have is that it has its priorities wrong, or it may not even have a way to configure priorities (unlikely), or maybe there is a to prioritize what is kept in memory but it only splits kernel/userspace memory so DE's that sit in userspace don't get priority (i.e. it's inadequate for a graphical operating system).
To be frank, as a desktop Linux user my biggest fear is that the Linux kernel is perfectly capable of prioritizing kernel/userspace memory, but it has no way to prioritize DE's. In other words, that the "graphical OS" use case of Linux is a second-class citizen, a feature bolted on top of GNU/Linux/Systemd. Because that would mean a lot of things are considered only from the perspective of a Linux server. This is only my imagination talking, since I'm not really involved with how Linux works. But to be fair I was never involved with how Windows worked either, and I never doubted it considered desktop a primary use case.
The issue is, if you don't have swap, then it's not matter of prioritisation: there are some things in RAM that can't be pushed out, regardless of how unimportant they are (so the only recourse is to terminate some processes, usually the ones using the most RAM. Linux the kernel by default tries really had not to do this, which is why there are userspace applications like earlyoom to do it, which is probably the better location for such logic).
And yeah, you can adjust the priorities and the latency/throughput tradeoff (even per-application to some extent), but it's a difficult thing to get right in general (what works for one use-case might make another a lot worse). I don't know of any DE that really tries to adjust this, though (not because the kernel can't, but probably because no-one on the DE side has really prioritised it or they have tried and it hasn't made a noticable difference).
A specific process can use mlockall to keep all its mapped memory resident and prevent swapping or page cache eviction. That's what earlyoom does so that it can stay responsive when memory gets low. It's unfortunately underutilized in other infrastructure. It's also all-or-nothing: everything stays resident until it's munlocked regardless of how frequently it's used.
I had hoped that something like Linux Pressure Stall Information (PSI) would become more useful for low-memory scenarios. E.g. you could put critical processes in a cgroup that could rate-limit swap-outs/evictions so that it was always responsive. There are some cgroup knobs that affect reclamation, but you need a really good guess about how much memory something needs, which makes it hard to use.
It’s even worse than that… you can hard lock a system with significant freeable memory left if you have insane vm.dirty_* settings (which is of course the case by default)
zram + no swap is a surprisingly workable workaround IME. The system slows down by a factor of 100 or so instead of 100000 or so, which allows to kill the offending process in a few seconds or have it killed by the OOM killer faster than a reboot.
The two mitigations are to:
- (somewhat counterintuitively) have swap enabled
- run something like earlyoom to stop the system from reaching a low-RAM situation in the first place.
However, a lot of recent bot traffic are sophisticated scrappers called "LLM's." You can tell claude to "research X from this www.example.com" and will automatically scrape it and summarize it, something that a LLM is perfect for. Gemini tends to share links instead, presumably because most of Google's revenue comes from ads served on those websites, so if it completely killed the traffic to those websites it would just make less money. Incidentally, I wonder if Claude/Gemini use an search engine-like "index" of all websites or it refuses to cache anything to always fetch "fresh" data.
If this is employed, I don't think the web is only going to be gatekept to Google devices. I think it will also be gatekept to Google's AI's.
Google would be able to display a captcha that no LLM could defeat, and then just let its own LLM pass through.
The same could be said about its other bots, such as the web crawler. Google's bot could crawl webpages that no other crawler would ever be able to simply because it has free pass to captcha-gated GETs. Although the same could be true already today.