Skip to content
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

Open
Maxzor opened this issue Oct 19, 2017 · 5 comments
Open

Open database and scanner? #10

Maxzor opened this issue Oct 19, 2017 · 5 comments

Comments

@Maxzor
Copy link
Contributor

Maxzor commented Oct 19, 2017

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

@rigred
Copy link
Owner

rigred commented Oct 20, 2017

Yes such a system is the idea of what we want to make.
However time is limited. I will develop and add features as I get the time away from work and other projects that currently have priority.

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
Cat

@Beanow
Copy link

Beanow commented Oct 22, 2017

@rigred as far as large files in git go, have a look at https://git-lfs.github.com/
For open databases you might like https://ipfs.io/ as well, with https://github.com/orbitdb/orbit-db being an example of how to run a decentralized database on top of IPFS.

@rigred
Copy link
Owner

rigred commented Oct 22, 2017

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.
Gzip for now saves a huge amount of space for sequential instruction address strings.

My internet connection is also not fast enough to spend time on that.

@Beanow
Copy link

Beanow commented Oct 22, 2017

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.

@rigred
Copy link
Owner

rigred commented Oct 22, 2017

Thanks, Yes I might set that up in future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants