Chameleon claims this on their website about clones:
Why Clones Underperform
Stable RFID requires accurate timing and tuned antennas for perfect coupling.
Cloned devices compete on price. Reducing the price means using lower-quality components (less precise, wider tolerance), which results in poor performance. Likewise, lowering testing standards means a cloning factory has fewer rejects - but customers receive devices of unproven stability and performance.
Ant = Anthropic, not the Chinese Ant. Good write up. There seems to be an inconsistency in Anthropic's justification of their spend on model training. According to them, there is a feed back loop of model training to become more efficient (with statements indicating that 90% of the company's code is AI-written), while at the same time the R&D expenses (which covers the training of new models) make an enormous jump. That is a bit weird. If you expect exponential growth, the exponent matters, not the base. Maybe Anthropic thinks that gobbling up all existing hardware via e.g. leasing allows them to iterate faster, thus increasing the exponent. But to me it seems this mainly allows for increasing the base (bigger models). I would expect that improving your models means that they become smaller and more efficient, not that they grow in parameter size. So it seems like Anthropic thinks that they need to brute force intelligence by creating increasingly heavier models (which indeed might suit their business model), whereas from a customer point of view increasingly leaner models are more 'fit' in llm evolution.
Don't know if Proton has any shareholders, but I they do, I hope they understand the CEO's position has become untenable, no matter his other real or imaginary qualities. It is (surprisingly) not uncommon for CEO's to have no clue about the business they are leading, but most of them at a minimum understand they should not spook their own customers. If Proton wants to restore trust, they need a leader that at least does not openly trash the company's own offerings.
Aside, with age becomes a deeper understanding of how realistic the Dilbert cartoons are.
I think that trust is burned already. I moved away from Proton to a German provider that sponsors its own infrastructure to be developed as FOSS (yes that means they are commoditizing their own product, but it is the SERVICE that's paid for).
Having shareholders means that the company WILL NOT continue to serve their customers. Any company that has external shareholders is untrustworthy. Everybody should consider them as disposable. It doesn't mean that you cannot have a deal with them, now but the parties should be aware that anything that you share will be misused. So if Proton has any external shareholders, it is already untrustworthy to me.
Therefore, they cannot really gain any trust by being activist shareholders and change leadership. They already supported a certain "persona" to make them money.
> I never thought about running the terminal emulator itself in a bwrap session, but I am eager to learn what those optimizations entail.
This is a pretty common scenario on immutable distros, and any power user who attempted to run a terminal emulator from a Flatpak would soon find out much of a pain it is. From what I recall, the main limitation is not having full access to the host processes, not having full access to the filesystem, and a few other Flatpak/bwrap induced restrictions.
Kwi solves the first problem by launching your shell directly on the host via D-bus, so the shell has full access to the host. Note that the terminal device itself still sits in the sandbox.
As for the file handling, it's mainly when you click on filesystem links, instead of going thru the xdg portal system like most portal apps, it again uses uses host execution method and calls `kde-open` to open the link via host's file handler, and furthermore, ensuring that the new window takes focus instead of remaining in the background (due to Wayland behaviour).
There's some other minor code around host process tracking and exit handling.
All of this makes the Flatpak version of the app behave like a native app (so don't rely on anything being actually sandboxed, if you're operating under that assumption).
Nothing too fancy honestly - Konsole inspects process metadata on the host via `flatpak-spawn`, which has a high overhead. Kwi makes D-Bus calls instead and saves a few processes/forks, and hence CPU. It's a fairly minor item on the list, all things considered.
There are some more ambitious approaches, like Ptyxis which runs an agent process on the host and talks to it over a socket pair, but I didn't want to invite that complexity just yet.
Interesting project. It seems it uses CodeMirror [1] in the Tauri frontend (60% of total code is typescript), but uses rust in the backend (30%). Surprising to see that Tauri is apparently good enough for the three platforms it needs to support (or it uses a lot of hacks, I don't know). The advertised memory reduction is remarkable as I expected a full web view to be a bit memory heavy. Not sure how this IDE keeps up with large documents or a lot of opened views though.
Even at 60 MB, assuming the app is on the order of "hello world", that's almost two orders of magnitude more overhead than Win32 on my x64 Windows 11 box (tested with C, assume Rust with the windows crate would be similar).
reply