zippie

10 ms·

31.
Do not enable KPTI for fixed Intel processors(lkml.org)
3 points by zippie 9y ago|0 comments
32.
by zippie 9y ago
Intel's investor call [1] is underway and they are describing the attack vector(s). Rogue data load seems to be most concerning issue according to Intel. Intel thinks this will need firmware and operating system updates to fully mitiga
33.
by zippie 9y ago
Data structures stored in kernel space, such as llds [1], will not incur the overhead of the TLB flush/load. I suspect that storing data in the kernel space in order to avoid maintaining a large application PD will become the norm, whe
34.
by zippie 11y ago
This is nice but the agent forwarding is a legitimate concern especially because a compromised host can take off with the private keys which are used while beginning the session. Most private keys are used for more than connecting to a sin
35.
Reminder: June 30th leap second(twitter.com)
1 points by zippie 11y ago|1 comments
36.
by zippie 11y ago
A clone is a clone. The main inplementation difference between a thread and process in Linux is COW, for all intensive purposes a worker process and a fork are the same in this use case. Neither have led to scalable web servers.
37.
by zippie 11y ago
Process per connection does not scale no matter how light weight, even with COW. kore's connection handling model is the reason apache2 mpm_prefork fell out of favor many iterations ago. The only valid argument to avoid a single event
38.
Apple Watch: What living with it is really like(wsj.com)
2 points by zippie 12y ago|0 comments
39.
by zippie 12y ago
Entering panic mode too fast, according to the chief of the CDC "there was a breach in protocol"[1] Frankly, this hospital mismanaged the index patient from the beginning and though the woman infected now wasn't on the initia
40.
by zippie 13y ago
Nuno Lopes attempted this first using LLVM in 2008: http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf I think the cost of the garbage collection involved in a JVM implementation vs LLVM significantly outw
41.
by zippie 13y ago
Supporting benchmarks that might be interesting alongside the OP: https://github.com/johnj/llds#wall-timings-in-seconds Same concept applies, reducing translations for page lookups reduces latency.
42.
by zippie 13y ago
A prime example of how to deal with and educate others a vulnerability. Presumably the bounty was distributed without incident which is worth noting the recent threads of bounties being forfeited.
43.
by zippie 13y ago
The log mechanism Prof. Stonebraker prefers, command logging vs ARIES, almost all newer data stores use command logging w/checkpoints (i.e., redis, mongo) and ship changes to other nodes similarly. After running a large production redi
44.
Google Latitude retired(support.google.com)
62 points by zippie 13y ago|68 comments
45.
GoFlow folds, refers foc.us as an alternative(flowstateengaged.com)
2 points by zippie 13y ago|0 comments
46.
by zippie 13y ago
C implementation: https://github.com/kshulgin/crope
47.
Hackers Steal $45 Million From ATMs(cnbc.com)
1 points by zippie 13y ago|0 comments
48.
by zippie 14y ago
There is, of sorts (rbtree), http://github.com/johnj/llds
49.
by zippie 14y ago
A different kind of use case: attribution. In my case I used this to correct an improper attribution to me, I searched for my name and came across: https://github.com/dks/TinyOAuth Except I didn't write OAuth.php. I wrote a different libr
50.
by zippie 14y ago
RAM isn't a cure all for big data applications and presents its own set of challenges. The largest issue is with traversal and data access latencies simply because of the virtual memory management overhead that is required. I've run into th
51.
Facebook employees can sell their shares now(forbes.com)
2 points by zippie 14y ago|0 comments
52.
by zippie 14y ago
The title is a bit sensationalist - there was incorrect code and it made the copy/paste rounds. Presumably all incorrect code is dangerous to some degree but I'm certain there's a more fitting title for this story. At any rate, here is a pu
53.
by zippie 14y ago
The answer focuses on branch misprediction but there is also another factor - CPU data prefetch. In order to offset increasing CAS latencies (largely due to the increasing number of channels) modern CPU's are greedy (in a good sense) and fe
54.
by zippie 14y ago
I don't believe most engineers brush off hash tables because of the worst case search. Or even storage costs or implementation complexity as the author suggests. My reason for shrugging off hash tables for most requirements: cost/complexi
55.
by zippie 14y ago
This is also important for index-heavy applications, llds for instance treats cache lines as registers and heavily optimizes for cache friendly operations: https://github.com/johnj/llds
56.
by zippie 14y ago
I'm either missing the reasons being backed up by Instagram's documentation or my sarcasm meter is completely broken this morning. 1) Dissent against OAuth; "OAuth sucks", "Don't use OAuth" 2) Focus on the fact that Instagram doesn't use OA
57.
by zippie 14y ago
I was trying to convey the opposite, as you stated, that inefficient memory access is not limited to the JVM.
58.
by zippie 14y ago
The need to access memory efficiently is also applicable beyond the JVM: http://news.ycombinator.org/item?id=4339089
59.
by zippie 14y ago
Just some background - the solution/benchmark spawned from an index lookup latency issue. In our search engine, we generate enormous b-tree indexes and store them in memory (rsync from master then mmap). After adding more logic, intersects,
60.
Virtual memory overhead for trees(github.com)
59 points by zippie 14y ago|19 comments

More ›