No, this is not a suggestion to write a *nix version of Everything ...
Everything 1.5 (alpha) comes with an Everything Server.
THis server is running on another Windows machine and collects local file information and sends it to all Everything clients that are "subscribed" to that server, to be added to the index of those Everything clients (= your regular Everything),
So there must be some underlying communication protocol and a well-defined handshake as well as information-set that gets exchanged in a specific format.
If that could be made public, "everyone" could write it's own Everything Server, that runs on Linux,Unix or even on Android.
As long as that 3rd party Everything Server follows protocol, it doesn't even matter (to Everything) if the database of that Everything Server is a csv file or the local indexing is done through a dir /s command.
[Suggestion] Everything for Linux/Unix/Android/ ...
Re: [Suggestion] Everything for Linux/Unix/Android/ ...
I would second this. A docker container, Linux based, would run fine on my Synology NAS, I bet 
Re: [Suggestion] Everything for Linux/Unix/Android/ ...
The Everything Server protocol is a little complicated.
I have put on my TODO list to write up the Everything Server specification and make it open.
Thank you for the suggestion.
I have put on my TODO list to write up the Everything Server specification and make it open.
Thank you for the suggestion.
Re: [Suggestion] Everything for Linux/Unix/Android/ ...
Is this still on your radar? Making the protocol public would be amazing and could lead to an entire ecosystem around Everything. I would love to be able to get near real-time results when search files on a remote linux server.
Re: [Suggestion] Everything for Linux/Unix/Android/ ...
I guess, right now, highest priority is the Windows version, which -hopefully- is still being developed, considering the latest version was released on 2nd of January.
BTW developer's last post here is also 2 months old. Really hope he is doing fine and he is just busy with other things.
BTW developer's last post here is also 2 months old. Really hope he is doing fine and he is just busy with other things.
Re: [Suggestion] Everything for Linux/Unix/Android/ ...
While acknowledging that Network Attached Storage (NAS) manufacturers or software developers are primarily responsible for this, I've long considered proposing a significant improvement. Open documentation of specifications and related details would enable the creation of tools for NAS scanning that rival the speed of other storage systems. This would be a tremendous advantage, given the vast amounts of data NAS devices typically hold. Efficient indexing of this data, similar to other storage types, would be transformative. Content indexing presents a separate challenge, but hopefully, solutions leveraging Large Language Models (LLMs) are being developed to achieve next-level file management—one that offers speed and efficiency without requiring substantial investment in ultra-fast NVMe SSDs. It might also be necessary to re-envision some of "Everything's" future internal mechanisms, creating separate databases for each storage type and distinct algorithms for indexing hot versus cold storage.
If NAS manufacturers, tech experts, and software developers would simply expose their internal file system protocols and database formats—much like the accessible NTFS/ReFS Master File Tables (MFTs)—then third-party indexing tools could finally attain "Everything"-like speeds. This would allow for direct access and indexing of these internal structures, facilitating lightning-fast retrieval of filenames, paths, and basic file information, thereby circumventing the frustrating inefficiencies of traditional network scanning for colossal datasets.
If NAS manufacturers, tech experts, and software developers would simply expose their internal file system protocols and database formats—much like the accessible NTFS/ReFS Master File Tables (MFTs)—then third-party indexing tools could finally attain "Everything"-like speeds. This would allow for direct access and indexing of these internal structures, facilitating lightning-fast retrieval of filenames, paths, and basic file information, thereby circumventing the frustrating inefficiencies of traditional network scanning for colossal datasets.