Infuse is another $100 license to sync watch history, when I already paid $100 for Plex a while ago (with the primary driver being 'sync watch history', which is the basic feature Plex provides).
Paying more money to use a different product, and then expecting all of my users to do the same, is a big hill to climb.
For how much Infuse gets praised I was disappointed in the UI/UX. Playback is great, but the browsing UI is terrible and offline downloads are really buggy (Just like with Plex for a very long time)
I’ve stopped using Claude on the desktop, just because of how slow the app is to start up and interact with. It’s an absolute clunker; I’m mystified why they can’t ship something that works well given their rhetoric about ai.
They vibecoded it, and admitted as much. Once it was able to self-vibecode, that's all they did. That's why it's written in React and uses gigabytes of RAM as a chat client.
Not only did they decide to write a terminal application in React, but it's 500K lines of code. It's strange because I'm sure Claude is capable of writing a decent TUI in C. It says a lot about the engineering culture at Anthropic, at least on the software side.
Oh, a nice subthread place to vent. Their CLI is so f tragic that it is ridiculous. It keeps scrambling the terminal, scroll and basic shortcuts keep breaking, I've used so many tuis and terminal apps and many of them are a single man operation and a side project and I have never seen anything so bad.
If I didn't know from experience that directed properly claude can be powerful, knowing that they used it to create that CLI would be instant runaway based on very reasonable heuristics - if they are not able to use their product to create a decent piece of software that is not even sophisticated then it seems futile for me to try.
I just do not understand. I feel like most HN could vibe code better claude CLI in claude than the CLI (and certainly just write one) than what we have to deal with to use subscription.
I could not agree more that Claude itself is a janky, hacky, crappy piece of software.
When management at $DAYJOB brought the hammer down and said, "Everyone has to use genAI all the time, OR ELSE," I expected to be blown away by the tool I was avoiding due to ethical concerns, aesthetic objections, humanism, and long-term thinking.
I was born away, but not in a good way.
The CLI is _bad_. I've seen it randomly fail to render anything at all on the terminal multiple times. It has a vim-mode, but it's painfully buggy, and I can literally outrun it - if I try to type too quickly after hitting Esc for normal mode, it just doesn't return to normal mode. It's I was keeping track of the bugs in the Claude TUI, but gave up because it was taking _too much of my time_ to do so.
If nothing else, I'd say Claude shows convincingly that success is not the default for vibecoding.
Yes, it technically does the job, and no, I don't think I've ever used a worse TUI.
Had to make a decision for a TUI I'm working on and opted for curses rather than something like textual. If I wasn't using an LLM to do some of the plumbing I'd probably have used textual to avoid the inconvenience.
There's a lot of opportunity to leverage LLMs to make codebases less bloated and less reliant on complex but human user friendly dependencies that not many people seem to be taking advantage of.
I thought they were all in on agentic coding? They are probably just building at a surface level with only an eye towards shipping, without considering the impact of all the changes. I've seen less and less coordination between engineers as well under that model. If that's the case (Claude Code is this way). it is sort of what you get, no matter the rhetoric about "make sure to review all your changes!" It's always trade offs.
It is surprising that the Claude web app lags pretty easily when using either chromium or firefox on ubuntu linux. Chats that delay my laptop work without issues on my ipad or iphone using the app.
The web app is definitely a bit of a problem. IF there is a native app on desktop or if claude cli is much faster, i haven't tried them.
All of the LLM web interfaces have serious lag when typing after a few turns, at least on iOS safari. I’m talking seconds to start rendering input after typing or when it needs to line wrap the input.
The Codex app slows to a crawl after a few back and forths. In fact it’s so bad that I had to completely switch to CLI, where at least it’s the optimized terminal that takes care of the rendering rather than whatever monstrous electron scaffolding they use
I'm with you. I have the Claude web app pinned as a PWA for quick queries, and then use the CLI for everything project-based.
I did consider experimenting with the Routines feature on the desktop app, but I'm leaning towards whipping together something with cron. I saw another poster here who has a daily PR summary routine that I think would be handy, as I have quite a few repos where I'm a sporadic contributor but would like to keep tabs.
It’s still dedicated ram on a separate chip, which is affected by supply shortages.
The ram is soldered onto the SoC in close proximity to the main arm chip. What’s different is that it is simultaneously addressable by cpu and gpu cores, not part of the same die as the apple silicon unit.
I’m not clear on the difference between atom and RSS. Atom seemed to be the better spec, but for my Astro blog I ended up sticking to the built in `rss` helper it ships with.
In the beginning was RSS 0.x. It was originally intended to be based on RDF. Compromises were made and it ended up dropping the RDF. The spec. wasn’t very good and had several ambiguities.
Some people forged ahead with a cleaned up RDF-based version and called it RSS 1.0, while other people went ahead with the ambiguities but without RDF and called it RSS 2.0. The person publishing RSS 2.0 considered it finished and refused to update it. There was drama.
A bunch of people decided that there was too much to clean up from within that mess and started a new format, Atom. This ended up being a much better spec. with an official RFC, but at this point everybody was calling any type of feed “RSS”, even if it was Atom.
It seems like the last update is from 2008, but the section on the differences has a few interesting items. I am not sure if it changed, but it says:
"The RSS 2.0 specification is copyrighted by Harvard University and is frozen. No significant changes can be made (although the specification is under a Creative Commons licence) and it is intended that future work be done under a different name; Atom is one example of such work."
There’s a lot to be said about his approach with go for simplicity. Python needs virtual environments, package managers, dependencies on disk, a wsgi/asgi server to run forked copies of the server, and all of that uses 4x-20x the ram usage of go. Docker usually gets involved around here and before you know it you’re neck deep in helm charts and cursing CNI configs in an EKS cluster.
The go equivalent of just coping one file across to a server a restarting its process has a lot of appeal and clearly works well for him.
Yes. It strikes me as odd how many people will put forward Python with the argument of "simplicity".
It is not. Simple. It may be "easy" but easy != simple (simple is hard, I tend to say).
I'm currently involved in a project that was initially layed out as microservices in rust and some go, to slowly replace a monolyth Django monstrosity of 12+ years tech debt.
But the new hires are pushing back and re-introducing python, eith that argument of simplicity. Sure, python is much easier than a rust equivalent. Esp in early phases. But to me, 25+ years developer/engineer, yet new to python, it's unbelievable complex.
Yes, uv solves some. As does ty and ruff. But, my goodness, what a mess to set up simple ci pipelines, a local development machine (that doesn't break my OS or other software on that machine). Hell, even the dockerfiles are magnitudes more complex than most others I've encountered.
"trivial" falls in the "easy" category. So it may not be hard to do. But what UV makes "easy" is managing something very complex under the hood.
Better example:
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]
While "easy" it is nowhere near simple. Aside from the entire complexity of the stack of docker, that `python:3.9-slim` it itself is very complex. It installs over 20 "dev" packages (from bluetooth via tk to xz), it downloads source files, builds a python runtime, (patches that?), installs pip, setuptools, does some (to python people probably familiar?) "wheel" stuff, etc¹. Point being: what you end up with, while easy to get, is very complex.
uv manages a runtime, some virtual environment to hot-swap that with other runtimes, it hooks into a package manager, manages additional tools (linter, typechecker, lsp, etc) and so on. What lies under that is very complex.
¹ I am well aware that node, ruby, php are quite similar.
