For this incentive to exist, the app needs to be such an obvious memory hog that users start identifying it as the source of the problem.
Even then, a lot is required for most businesses to prioritize this (presumably) temporary issue at the cost of things like: participation in the AI race, other features, bug fixes, new markets etc.
Heck, sometimes software is so inefficient that it costs developer and tester productivity but a fix is not prioritized for years.
tldr; devcontainers let you completely containerize your development environment. You can run them on Linux natively, or you can run them on rented computers (there are some providers, such as GitHub Codespaces) or you can also run them in a VM (which is what you will be stuck with on a Mac anyways - but reportedly performance is still great).
All CLI dev tools (including things like Neovim) work out of the box, but also many/most GUI IDEs support working with devcontainers (in this case, the GUI is usually not containerized, or at least does not live in the same container. Although on Linux you can do that also with Flatpak. And for instance GitHub Codespaces runs a VsCode fully in the browser for you which is another way to sandbox it on both ends).
Basically we do not rationally analyze what work can be automated and what work is forever safe. We just assume that "sexy work" is safe, and work backwards to figure out how to explain this belief to ourselves.
honestly, I interpreted your comment as "Taskwarrior is unusable shit" since it had a pretty negative tone and came from a user named throwaway27448.
Actual accessibility is a different topic. Honestly I don't know much about the a11y of CLI apps in general. Is there something that makes Taskwarrior bad in that regard? Is it about the way it forms things like list outputs or tables?
I was considering adding a full offline mode but here is my thinking: that is actually a feature/concern that would be separately useful, so it should not be baked into blogtato. And there might be already some pretty good options out there.
For instance, `wget` is a pretty widely used HTTP client that is able to mirror links for offline access. Then you can use standard tools such as `grep` to search in all the offline content. And `blogtato` does already have an export feature, so it is almost trivial to write a script that saves all posts for online content.
So perhaps what should be done here is find a user friendly tool for offline access/search for web content and just add some convenience features to `blogtato` so that they integrate very easily.
i do not find the interface of taskwarrior inaccessible at all, i actually really love using it and find it largely intuitive. Not necessarily for doing super complex stuff, but that is not something I ever wanted anyways
that was actually a lot of fun. I think it has the potential to grow into a bigger game.
Bug Tux Racer vibes btw! I think adding some music and perhaps snowfall could make it even more immersive
edit: and i think you could easily make it feel more detailed by adding a texture for the snow,and increasing the resolution of nearby terrain by modulating it with some precomputed fractalized perlin noise. So basically "free" detail that only exists in the rendering logic, does not influence the complexity of the heightmap. and perhaps you could replace the trees with sprites that are images of real trees (stylized to the visual style you're going for)
It's possible that the training data (and research data) is already out there, just not (yet) combined into a single open source CAD kernel.
Then again, the success of such a project might depend on other factors. Given the complexity of the task, I can imagine that just "lucking into" the right design decisions early on could have a major impact.
I only used it for some hobby modeling, but I have to say it's fantastic and very impressive.
It seems like it's fully community-maintained, there is no big company or foundation behind it. Honestly it's hard to believe!
There was just one major problem, the infamous "topological naming problem" which caused issues downstream is you edited a non-leaf node. That was pretty frustrating to deal with, but in later releases they fixed it I think. (Have not tried it since because I didn't have anything to model)