Is there any way to recover a "bricked" Clara color? I bricked mine while trying to install nickel and koreader. Haven't been able to recover it since.
I think you'll need to replace the mainboard with one from ifixit.
Not aware of a debug interface, but in the absence of that, you'll need to desolder the nand module and replace the files there with the help of another owner. The mobile read forums are where you can connect with fellow owners.
There is a market for that, indeed. Hardened container images and hardened CI actions have been a thing for a while, with some companies providing exactly that.
In my experience, lean will show that it's correct, but does it not lose the mathematical intuition that led to the result? As far as my experience goes, that's really hard to encode in lean itself.
Could we maybe get more information about the problem from the LLM trace itself here?
As proofs become more and more complex, we will need two AI pipelines: one to generate the LEAN proof, and a second one to extract useful lessons for mathematicians from the LEAN proof.
No, something truly better does not exist yet, but that doesn't mean that it won't. Lean is young compared to Isabelle or Rocq, but actually quite old in absolut terms (and especially in AI terms).
Surprisingly, it's the whisper model itself that does that. I find that it's also good with false starts, often correcting something like: "uhm, we could...we can go there" to just "we can go there", if spoken rapidly enough.
If anyone wants to try this without the intricate setup, if you have a linux system, you most probably can just press Ctrl+Alt+F3 and drop into a tty console directly. To return, you have to press Ctrl+Alt+F1 or Ctrl+Alt+F2. You also have multiple consoles, up until F12 probably.
I used to use this a lot when trying for a less distracting desktop, just like in the original post.
I'm a proverbial greybeard and Ctrl+Alt+F7 used to just be what you did to get back to your desktop GUI.
FWIW, right now I'm typing this from Ubuntu Studio 24.04 and it's Ctrl+Alt+F2 to get back to the GUI. Ctrl+Alt+F1 shows you the bootup output scroll, +F3 to +F6 will give you a login prompt to drop into a shell. +F7 to +F12 just give me a blinking cursor un the upper right corner of the display.
I'm kinda surprised only +F3 to +F6 give me a shell login. Three isn't that many.
I think Ctrl+Alt+F1-F7 are Kernel provided Virtual Console things, and technically they can be connected to different things, I think like VC 5 -> /dev/tty5 -> a thread in /sbin/getty? The VC 7 used to be often opened up for X, but Ubuntu moved X to VC 1 at some point. I guess it's VC 2 now.
Maybe this have changed over the years, and I rarely if ever used these combinations to switch to TTY except for emergency (OOM, or window manager breakage), but on every Linux system I ever used, graphical mode was on (Ctrl+Alt+)F7.
Using CachyOS right now, gdm/mutter/gnome ended up on Ctrl+Alt+F1, I can't remember if it was crunchbang or some other older distribution, but been others too using various numbers. I agree F7 is most common though.
Doesn't llama.cpp (or similar) have to evict the kv cache for this, so that performance is degraded when running multiple sessions? Or how do you load a model in memory and then use it in multiple sessions? I am still learning this stuff
The model is loaded once and can be used for multiple sessions, and even parallel requests.
llama.cpp uses a unified KV cache that is shared between requests (be they happening in parallel or not). As new requests come in, they'll evict no longer referenced branches, then move to evict the least recently used entry, and so on.
If you come back to a session that's been evicted it will just be parsed again. This is a problem only on very long context sessions, but it can still be a problem to you.
So one way to reduce such evictions (and reduce KV cache size significantly as a bonus) is to reduce the number of kv cache checkpoints.
Checkpoints allow you to branch a session at any point and not have to recompute it from the start. If you find that you rarely branch a conversation, or if you rely entirely on a coding harness, then setting ctx-checkpoints to 0 or 1 will save tons of VRAM and allow more different sessions to stay in VRAM. This is especially true for models with very large checkpoints (such as Gemma 4).
There are so many flags to llama.ccp that I won't try to say anything too strong, but I believe things related to `--kv-offload` mean you can have the KV cache in GPU VRAM, regular GPU RAM, paged to disk, etc...
I'm on a Mac with unified memory, so I can't easily benchmark it for you, but I think a PC with 64GB of regular RAM and a 24GB gaming card could swap between multiple sessions without too much pain. The weights could stay resident on the GPU.
On the other hand, I did just dump some Project Gutenberg texts into a prompt, and building that cache in the first place was slower than I though it would be.
How do you use `pi` to ssh? I use `oh-my-pi`, and tried the `/ssh` command, but I couldn't get it to work. Then I saw a suggestion somewhere to just run `!ssh` to place things into the agent's context.
Is there a way to use it like "The current directory is at `ssh server`" and have the agent work from there?
reply