Unless something changed very recently neither vim nor neovim defaults to storing persistent undo files in ~/.cache. It's application state, not cached data.
The undodir option in vim defaults to the directory of the file, and in neovim it defaults to ~/.local/state/nvim/undo/.
They're calling it "live" and "near real-time" because they're aggregating the data from underlying sources daily, whereas traditionally that happened only on much larger time scales.
It's not very fast compared to most things often called "live", so perhaps it's not a great label for this demo viewer, but the goal of the project seems to be to make the data available for research, not so much for this map.
> I’m pretty sure Kagi’s entire pitch is that they’re an alternate and original dataset. Theirs is the only search engine whose data isn’t based upon google or bing’s databases.
It's not. In addition to their own indexes the results include calls to "all major search result providers worldwide"[1].
There are independent search engines that only use their own index, like Mojeek[1]. Kagi is explicitly something like a search engine aggregator.
> Performance is similar to when I self-host Forgejo on a dedicated VPS where I'm the only user, which is super fast.
I don't mean to be negative, but that's probably because it's pretty much the same thing. Codefloe is tiny. Some quick counting shows it has a grand total of 1012 registered users, including bots, and 1416 public repositories of which the top 3 with the most stars (I know this is a mostly meaningless metric, but for scale) have 27, 13, and 8. It's too small to run into scaling issues.
Numbers are just one thing, what counts is the effective request traffic.
We are just as large as we are and can't do anything about it ;)
The only thing we can influence is to stay fast from day to day, watch our disk and storage and adjust things if needed.
I am quite confident that we can take multiple tens of thousands, if not hundred of thousands of users (with the respective request ratio share of active and dead accounts) with our current hardware stack. We'll see how it goes when we eventually get there.
The reason this seems so weirdly hard is that you're not supposed to be doing it. You provide sources and instructions on how to build them, and then your job is done. Users can follow those instructions. If you want to you can also build a binary with an old version of libc and distribute that to help users who don't want to compile it themselves.
Packaging it for a distro is someone else's job, and they'll take care of concerns like Debian's dependency policy. If they want to package it in the first place of course.
This isn't a good dichotomy though. Either "Build it from source" or "Wait for a professional 3rd party to package it for you".
The idea that your OS distro needs to explicitly support and package every software you could ever want to use seems crazy to me.
Both users and authors want the same thing: low-effort, high-quality distribution of software.
Personally I put my support behind flatpak for GUI, mise for CLI/TUI, but it's not a perfect solution and I occasionally bail out to homebrew/linuxbrew.
> The idea that your OS distro needs to explicitly support and package every software you could ever want to use seems crazy to me.
No one is under that impression, not maintainers nor users. The idea is that every software that is common and/or popular and/or useful enough to someone who is willing to maintain it, is managed by the distribution/repository staff itself, as they're the ones who knows the distribution best. Some software requires patches to be fully compatible, some distributions expect certain files in certain places and so on, and no one expects every developers to understand the idiosyncrasies of every distribution they want to potentially ship to.
But that doesn't mean ALL software you use has to come from these official software repositories maintained by the distribution. Most of my packages are from the official Arch repositories, maintained by people who know what they're doing extremely well, and almost gives you certain "guarantees" by the mere existence in that official registry. But then some software I use is installed via the AUR, which is more like npm, where anyone can publish anything, close review of everything is required for this, it's the wild west. And some software I install/run by having local GitHub checkouts I build binaries from. Finally some are just stray binaries in ~/bin/ that I've had for decades and don't even know where they're from anymore. All are "correct" for what purpose they serve, yet the official Arch repositories still remains extremely important and valuable for stability.
Still, the software that almost all of the distribution users use, like wayland or systemd, is maintained by these people and explicitly "supported" by the distribution, as far as that term holds in FOSS.
> This isn't a good dichotomy though. Either "Build it from source" or "Wait for a professional 3rd party to package it for you".
Somebody has to do the work. Apparently you won't accept it for that to be the developer, the user, or a "professional third party" (whatever "professional" means here). What exactly do you want?
> Personally I put my support behind flatpak for GUI, mise for CLI/TUI, but it's not a perfect solution and I occasionally bail out to homebrew/linuxbrew.
So third parties. Things that have reinvented "distributions", arguably badly. Are you saying they're not "professional"?
1. I want it to be easy for developers to publish their own packages.
2. I want it to be easy for users to install these developer-published packages.
> Are you saying they're not "professional"?
I regret using the word professional, I was replying to the claim GP made:
> Packaging it for a distro is someone else's job
Well I (as a developer) want to publish my own software without waiting and hoping someone else will do it for me.
> Somebody has to do the work.
Yes, I (the developer) want to do the work. The whole point of the article is that its painful to do today. I'm interested in how we make the packaging work easier so the developers can do it.
> [...] So third parties
the whole 3rd/1st party question is whether a developer can publish their own package. In most cases they technically can (taps, PRs, flathub, Debian registries, so on) but run into lots of issues along the way.
> Packaging it for a distro is someone else's job, and they'll take care of concerns like Debian's dependency policy. If they want to package it in the first place of course.
Yup, this is why I think so many people feel so much friction about it. On Windows and macOS, the developer is usually responsible for the entire thing, even shipping installers for users. Linux distributions tend to split the roles, and as mentioned, once you provide sources and how to build it, you're basically done and it's up to others now.
That sounds like you could have a situation where the developer wants me to run the app, and I want to run the app, but nobody at the distro I use has packaged up the app, so we're blocked.
> but nobody at the distro I use has packaged up the app
But you're "at the distro", and you want to use it, so you package it :) You might want to be nice to others too, so you make that public. Eventually, the community might end up relying on it, and the package gets an official maintainer from the distribution itself.
So, manually configuring and updating software is complicated and a waste of time. (I'm not even mentioning the stupid thing called "installation and uninstallation".) With package managers, we have displaced this complicated waste of time so that the responsibility for it becomes vague, and as a result sometimes you can't have a nice thing.
> and as a result sometimes you can't have a nice thing.
I've been able to have all the nice things I've wanted, but I also sit down and learn the distributions I use, including how to package stuff, so I can do that myself for things I want to use :)
Some distributions like Arch makes this "self-packaging" extremely easy and simple, and today with LLMs I'm guessing you can get the agent to package most standard software people ship today in under 5 minutes into something acceptable for your own use.
Sorry, I don't have those skills, or any spare time.
And if you want a system whereby software only gets made available if distro-providers care enough, then that's fine. But you're putting a filter between the software producer and non-technical users, and you should be aware that this is a choice you're making.
> It has worked for decades and many thousands of packages just fine
And yet insane quantities of programs used by millions are only available via raw .deb file downloads, or random alternative PPAs, or via programming language package managers.
The distro maintainer system is impressive, and I’m thankful for it. But saying “it has worked for lots of packages” says nothing about the many it has not worked for.
If they're not using your software they're not your users.
You seem to be treating this like a commercial endeavor in which you have much to gain from adoption by nontechnical people. I don't really see why though. It looks like you're developing non-commercial open source software for an audience of developers.
You are taking on the responsibility of being compatible with a large variety of different people's opinions on how software should be built, configured, and distributed. Yes that's a lot of work. Distributions have people willing to do that work for software they or their users (who can ask) care about.
Linux evangelists on the internet are some of the most unhelpful and useless people you will ever come across. My condolences in advance for every "ackshually you must pray and wait 10 years that some Debian maintainer to pick it up" reply.
I get that but I feel like its a bit different for linux users. The ecosystem has way more folks that are used to building their own tools relative to Win/Mac. Especially for something like nix. I've built nixpkgs for tools I've wanted to try & use. For something like this, I'd stick with cargo and let others do the packaging.
> You provide sources and instructions on how to build them
Have you ever interacted with actual users? This is absolute no-go which will only bring world of pain on you and your issues list and your email and your Discord and whatever other way you decide to talk to users....
No, this device was only discontinued this year, you can still buy accessories and it still receives software updates.
It just turns out their software has flaws that break the update process after a few years of sitting unused. Not great, but luckily there are workarounds, as this article walks you through.
reply