some

I'm really interested in the concept.

I would like to see community-oriented search engines. But I don't know if "the community" is viable really. It would better be for communies. I just downloaded the browser extension and it lets you see the pages it is crawling; they are the sorts of things that would be of interest to a lemmy type community--- a lot of nerd stuff. Which is of interest to me. That's why I'm here. :)

What if I am in an online community interested in a different part of the web--- say celebrity gossip and royal watching. A network of forums, comment sections, socials, chats etc with thousands of people who are at least casually interested and some hundred who are very motivated. Like everyone else the web is getting harder for us to navigate. How realistic would it be for us to spin up an instance of this to make our own community search engine? This community does not want to see a bunch of stackoverflow, gihubs, arxiv papers, tech news or the other stuff I am seeing float past me in the crawling extension.

It seems that the place where this kind of thing is somewhat documented would be https://book.mwmbl.org/

but it's pretty vague.

mumble is already the name of FLOSS voip software so they're probably better off with the existing name. Which I don't love on first glance but there's probably some rationale for it.

Is there any specific reason to keep the docs in the wiki section? Vs markdown documents right in the wiki itself?

For my self I like to document in the code itself. It has one major benefit which is: I always know where the information is to be found. But there are some problems with it such as

• creates conflicts when merging changes from another repo or branch

• it makes the git history a lot messier because you have some commits on functional code and some on comments, all mixed up in a single document. I know with fancier git this could be tidier but I can't reliably work at such a high skill level

• comments are not subject to syntax formatting so harder to read

• source document itself becomes too long to read and hard to understand

• extremely contextual to my skills and challenges at the time when I wrote the code; not what I will need to know in the future and not what others need to know

So not always the way to go.

thanks I was wondering about that but forgot to specifically ask :)

This is a case where both tools are invaluable.

The original find has much more comprehensive options. Of course it is extensively documented and you can find all kinds of information online about how it works and how to combine it with other tools to accomplish all kinds of tasks. And it's GPL which is always preferable.

fd has a narrower range of functionality but goddamned it really is faster. fd can run several searches on the whole hard drive's contents while find is struggling to get through just a single comparable search on the same set of files. For simple tasks, the cli usage for fd is less to remember and less to type.

If I had to choose, I'd stick with find because it can do everything, even if it's slower and more cumbersome. But luckily, don't have to choose, just have both and use them as appropriate.