milli VS evdi

Is this a posting list? There is a lot of bioinformatics in this post, but if I squint, some of the problems do look like general information retrieval problems. Even the discussion of ordering the arrays by mass sounds like search relevance scores and makes me wonder if it makes sense to try to get something off the shelf like meillisearch/milli or tantavy to support this use case.

I'm currently not using any tool, although I am playing around with binding Milli and the most up-to-date Mentat fork to emacs with emacs-module-rs.

Yeah, we have already done that, the internal engine is called milli and could even be published on crates.io one day! The issue is with the design of the storage system itself, we use LMDB right now but maybe we can find another way to index faster and to be more oriented to distributed systems.

They have another prototype engine with more advanced features and performance too.

https://github.com/meilisearch/milli

You can look at the milli repository this is the library that we use and work on. MeiliSearch is the HTTP actix-web based server that serves the milli indices.

This library is the main bottleneck of the new MeiliSearch search engine. We will soon release a beta version, keep watching!

Working on the new MeiliSearch engine, reworked from scratch! There already is excellent external contributions 🎉

git clone https://github.com/DisplayLink/evdi.git

So I'm currently on Ubuntu 22.10 with Mesa and asahi-edge kernel. You need both to allow using primary GPU as source output. I'm using evdi 1.13.1 with the correction to set the module to the 1.12.0 to run the script displaylink from Synaptics for Ubuntu.

The RPM version never worked for me. It's only useful for getting the services installed. After that clone the repo from https://github.com/DisplayLink/evdi and change to the devel branch. Run make and sudo make install. If you use SecureBoot you also need to sign the resulting evdi.ko with your key. After that restart displaylink.service or reboot and it should work. At least it did for me. I's been a while since I had to use it.

Uninstallation steps complete. darren@pop-os:~/displaylinkfix$ ./displaylink-driver-5.6.1-59.184.run --noexec --keep Creating directory displaylink-driver-5.6.1-59.184 Verifying archive integrity... 100% MD5 checksums are OK. All good. Uncompressing DisplayLink Linux Driver 5.6.1-59.184 100% darren@pop-os:~/displaylinkfix$ cd ./displaylink-driver-5.6.1-59.184 darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$ curl -L https://github.com/DisplayLink/evdi/archive/refs/heads/devel.tar.gz -o evdi.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 80603 0 80603 0 0 179k 0 --:--:-- --:--:-- --:--:-- 179k darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$ nano darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$ nano evdi.tar.gz darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$

I'm afraid this might be a hardware issue, maybe with the cable. I don't have a second cable to swap out unfortunately. A new one won't be here until Saturday. And it seems like a hell of a coincidence for the cable to fail when there's other issues reported within the last few days that seem very similar.

https://github.com/DisplayLink/evdi states

Theres a bug in the 6.2 kernel right now with at least the evdi package (dont know about evdi-git) but can be fixed with a patch. Pr for it is already open but yet to be merged https://github.com/DisplayLink/evdi/pull/401