Eikon

6 ms·

91.
by Eikon 1y ago
I have no doubt that JuiceFS can perform “thousands of operations per second” across parallel clients. I don't think that's a useful benchmark because the use cases we are targeting are not embarrassingly parallel. Using a bunch o
92.
by Eikon 1y ago
The durability profile before sync should be pretty close to a local filesystem. There’s (in-memory) buffering happening on writes, then when fsync is issued or when we exceed the in-memory threshold or we exceed a timeout, data is sync-ed.
93.
by Eikon 1y ago
The bench suite is published at the root of the repo in bench/. Stating “a bunch of claims” seems a bit dismissive when it’s that easy to reproduce. JuiceFS maps operations 1:1 to s3 chunk wise, so the performance profile is entirely u
94.
Show HN: ZeroFS, the Filesystem That Makes S3 Your Primary Storage(github.com)
64 points by Eikon 1y ago|40 comments
95.
by Eikon 1y ago
I abandoned that idea as soon as they launched their weird crypto-coin stuff. Also, can we backup our messages yet on iOS?
96.
by Eikon 1y ago
You accuse me of doing exactly the the thing you keep doing: deflecting with random stuff and ignoring the substance. Meanwhile, if I was just a troll, you wouldn’t keep coming to this thread to prove me right. I’ll leave it here.
97.
by Eikon 1y ago
The technical vulnerabilities I reported are factual regardless of organizational relationships. The concerning issue here is that my private security disclosure was forwarded to a public, Google moderated venue, without consent. Then, I wa
98.
by Eikon 1y ago
There's a distinction between "Corrupted seed" and corrupted PK / password. The seed is provided without validation or checksuming, generating perfectly valid keys on the fly from unknown entropy quality. If you have bad
99.
by Eikon 1y ago
You could have at least disclosed your current position. "Staff Software Engineer, Google - Full-time" That really does not read well, especially on a post that was flagged and not seen since _hours_ on the "main" websit
100.
by Eikon 1y ago
This is not a strong take, the "fix" doesn't completely fixes the vulnerability. Passwords or private keys are not the same as a user-provided crypto-seed without checksums. This is supposed to be critical PKI software. It&#x
101.
by Eikon 1y ago
This is not a strong take, the "fix" doesn't completely fixes the vulnerability. Passwords or private keys are not the same as a user-provided crypto-seed without checksums. This is supposed to be critical PKI software. It&#x
102.
by Eikon 1y ago
I'm not even asking for money!
103.
by Eikon 1y ago
I think "critical" is due to the context, it's supposed to be trusted software that participates in the trusted public key infrastructure. If your seed is corrupted, the whole model collapses. There's not a ton of divers
104.
by Eikon 1y ago
This is not true, 1. Operator correctly runs: cat /dev/urandom > seed.bin 2. Filesystem corruption fills seed with nulls/spaces (happens in production) 3. Sunlight silently generates predictable keys from corrupted seed 4.
105.
Google says "not a security vulnerability", quickly fixes without attribution(groups.google.com)
45 points by Eikon 1y ago|30 comments
106.
by Eikon 1y ago
Thank you! SlateDB is indeed using bloom filters. Here's the end of the tree on a test instance where I loaded 50 million certificates - the latency is basically indistinguishable from an instance with only a few thousand records: htt
107.
by Eikon 1y ago
> The purpose of temporal sharding is to allow log operators to reclaim storage space used for expired certificates But you lose historical auditability that way, for arguably very little space reclaimed. I'd say it's not worth
108.
by Eikon 1y ago
Yes, temporal sharding would theoretically become unnecessary with this system. The current implementation should be capable of handling the entire historical CT dataset without requiring time-based partitioning. On storage efficiency, Comp
109.
by Eikon 1y ago
I'm excited to share CompactLog, a Certificate Transparency log implementation written in Rust that explores an alternative approach to CT scalability challenges. Certificate Transparency logs face immense scale - millions of certifica
110.
CompactLog – Solving CT Scalability with LSM-Trees(github.com)
30 points by Eikon 1y ago|9 comments
111.
Show HN: CompactLog - Solving CT Scalability with LSM-Trees(github.com)
4 points by Eikon 1y ago|1 comments
112.
by Eikon 1y ago
I'm excited to share CompactLog, a Certificate Transparency log implementation written in Rust that explores an alternative approach to CT scalability challenges. Certificate Transparency logs face immense scale - millions of certifica
113.
Show HN: Certificate transparency log with LSM-tree based storage(github.com)
4 points by Eikon 1y ago|0 comments
114.
Show HN: RFC6962 certificate transparency log with LSM-tree based storage(github.com)
1 points by Eikon 1y ago|0 comments
115.
by Eikon 1y ago
I run https://www.merklemap.com/ a certificate transparency / subdomain search engine. I’d say that this kind of projects are not different than any entrepreneurial endeavor, and the biggest challenge is usually acquis
116.
by Eikon 1y ago
I am working on https://www.merklemap.com/ a certificate transparency search engine.
117.
by Eikon 1y ago
> Both your points do absolutely not mirror my experience. In traditional career paths (established company) a diploma helps a lot -- for some roles you won't even be considered otherwise. For a first job? Maybe. I don’t have one an
118.
by Eikon 1y ago
> It's a big club and you won't be in it if you decide to self-study. That's the cold, hard truth. This almost reads like conspiracy. There’s barely anything like that in reality, and the kind of network people finds at sc
119.
Scaling Certificate Transparency and Postgres with 100B+ Rows of Data(blog.transparency.dev)
3 points by Eikon 1y ago|0 comments
120.
Merklemap: Scaling Certificate Transparency with 100B+ Rows in PostgreSQL(blog.transparency.dev)
4 points by Eikon 1y ago|0 comments

More ›