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.
Agreed that a website should be fine, but (Dutch) banks require the app as a second factor to log into the website. Fido2 hardware tokens could replace the bullshit requirement of "choose Apple or Google to be your overlord in order to use our service".
Ehm, no. They don’t all do at least. For one, Rabobank does not require it. You can use the app to authorize in the browser. But for big transfers you still need their Rabo Scanner (which you get the first one of for free).
It's being phased in due to regulations. They're allowed to offer insecure SMS 2FA to confirm transfers, etc. as an alternative but are supposed to move away from it.
The EU has regulations requiring banks to move to an app with device and app integrity checks. SMS 2FA is temporarily permitted for backwards compatibility but is explicitly considered a legacy approach that's being phased out due to being insecure.
JetBrains should focus on the artisanal engineers and the 'vibing' engineers who need to code by hand from time to time. They have a big moat already. I imagine they try to keep the user base from fleeing their platform, but I think they have already covered prompt integration. There is imho no value in yet another LLM wrapper that seems to be totally unrelated to the existing offering, at least no monetary value.
I would urge JetBrains to put all their LLM power and human brains at work to slash their IDEs backlog and deliver the GOAT of all IDEs. Building IDEs is their strength and there will always be a market for that category.
Pretty sure following this advice would kill them really fast. Only 5% of code will ever need to be hand typed if that. They have analytics that show their IDEs were used by people who deeply card about efficiency and there US nothing more efficient than managing cloud agents.
In a few years we won't even be reviewing code. We will have abstracted code into building blocks and review those abstractions only.
> Only 5% of code will ever need to be hand typed if that.
You are talking about the 'vibing' demografic. Not all of them would use JetBrains, as not all programmers did before the advent of LLMs. But for the time they do have to be in the code, JetBrains could be their best option. They are in a unique position to cover their existing offerings in a gold finish.
> Pretty sure following this advice would kill them really fast.
I don't think so. There is no money to be made in llm wrappers. Their market might have shrunk, sure, but on the other hand they should be able to bring down their expenses significantly while at the same time bringing their backlog to zero. If not, they have nothing to fear from AI and the hype will be over some day.
> that it was the Russians who hacked the phone and the Dutch got a copy of the contents
The Russian spy gave access to the GROe server, where a copy of the contents lived. Later on, in the beginning of 2018, the MIVD got direct access to the phone.
reply