Flatpak serves a need, there are plenty of users who like it and there are probably even more who just use it without thinking much about it. Personally, I like it for a few reasons:
- Being able to install something dependency-heavy with just one package
- Sandboxing
- Getting a newer package than what my distro provides
- Being able to update apps independently of the rest of the OS
- Being able to easily install apps that my distro doesn't provide
The people who hate it, especially without giving a reason, are largely irrelevant when flatpak is filling a need for so many other people. Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise.
> Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise.
And how do you know the userbase for GP's specific product is all Flatpak users? In fact, based on their comment, it appears as though they are explicitly not, hence their vocal frustration.
Not the person who wrote that but i also avoid anything related to Flatpak. The reason is that it adds a lot of extra friction to anything it touches (despite what its proponents may claim), apps ignore various settings, it wastes disk space with pointless duplication and a bunch of other issues i do not remember right now (it isn't like i write those down - i just sometimes decide to try it for something exactly because i forgot all the issues i faced and somehow someone convinced me things aren't as i remember, then recoil in horror afterwards as it turns out things are as i vaguely remember -- of course the main thing i always remember is the distaste i have for the thing, not the individual microdetails that led to the distaste).
Ultimately if something isn't in my distro's repository, i try to compile it from source and if that isn't available, i just use something else.
It's superfluous, goes against unix philosophy, solves problems that don't exist in the most obnoxious ways possible, and your distro packager is certainly better.
I think I was sold the full agentic coding hype all over the internet. You give it a try and it does write a feature really fast. Impressed you test the boundaries more and more and before you know it this has become your new workflow. Breaking free of this again is harder than you'd think even when you do realize what a mess is generated in the process.
Perfectly summarizes what I hate about AI code. The diff looks fine but if you take a step back its an absolute mess. I mean have you looked at the Claude Code or Openclaw codebases? that is the result of full on vibecoded. A bloated unattainable mess that no one understands.
If I tell it to implement something it will sometimes declare their work done before it's done. But if I give Claude Code a verifiable goal like making the unit tests pass it will work tirelessly until that goal is achieved. I don't always like the solution, but the tenacity everyone is talking about is there
> but the tenacity everyone is talking about is there
I always double-check if it doesn't simply exclude the failing test.
The last time I had this, I discovered it later in the process. When I pointed this out to the LLM, it responded, that it acknowledged thefact of ignoring the test in CLAUDE.md, and this is justified because [...]. In other words, "known issue, fuck off"
> If you ever work with LLMs you know that they quite frequently give up.
If you try to single shot something perhaps. But with multiple shots, or an agent swarm where one agent tells another to try again, it'll keep going until it has a working solution.
Yeah exactly this is a scope problem, actual input/output size is always limited> I am 100% sure CC etc are using multiple LLM calls for each response, even though from the response streaming it looks like just one.
Context matters, for an LLM just like a person. When I wrote code I'd add TODOs because we cannot context switch to another problem we see every time.
But you can keep the agent fixated on the task AND have it create these TODOs, but ultimately it is your responsibility to find them and fix them (with another agent).
Using LLMs to clean those up is part of the workflow that you're responsible for (... for now). If you're hoping to get ideal results in a single inference, forget it.
It makes me so exhausted trying to read them... my brain can tell immediately when there's so much redundant information that it just starts shutting itself off.
reply