-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open database and scanner? #10
Comments
Yes such a system is the idea of what we want to make. Currently the repo is acting purely as a archive of sandsifter tests, they have to be compressed due to their large size. A database documenting these instructions would also have to be custom designed to handle this compression issue and to reduce duplication of instructions across different CPU's. I am open to any suggestions and Ideas and will update this project accordingly once development starts on such a system. Kind Regards |
@rigred as far as large files in git go, have a look at https://git-lfs.github.com/ |
No we dont need an IPFS setup for this. KISS principle I also want to keep the repo as small as possible because nobody want's to download such a huge repo. Every CPU scan can be about 200Mb, and on Ryzen for some reason it's 1.4Gb. My internet connection is also not fast enough to spend time on that. |
Fair enough. None the less Git LFS is worth using exactly to keep the repo small. Otherwise every version of every scan needs to be downloaded to clone the repo, where LFS will track references to those files instead keeping your git history clean and fast. |
Thanks, Yes I might set that up in future. |
Hello,
The intention is great, but I find compressed logs not that handy.
What about an open database with per chip the three categories : undocumented instructions, software bug, hardware bug?
With a script to check binaries in your system (linux/windows/...) against your corresponding database entry?
BR
The text was updated successfully, but these errors were encountered: