Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dilyevsky
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
4 ms
·
1.
▲
by
dilyevsky
5d ago
Interesting, we had developed a very similar framework for our internal agents: https://github.com/apoxy-dev/clrk For us main use-case was intercepting all network I/O including LLM providers, HTTP, and random TCP
2.
▲
by
dilyevsky
8d ago
load-bearing was a meme phrase used sarcastically on twitter long before claude started overusing it.
3.
▲
by
dilyevsky
8d ago
> A model is not an appropriate solution that's a bold statement without any supporting argument. more like an opinion really. specially trained classifiers can be very good. sentiment analysis has been a thing for a while now, ther
4.
▲
by
dilyevsky
9d ago
they did rebuild their serving layer from fastapi to some rust thing so...
5.
▲
by
dilyevsky
10d ago
there is a number of different methods. One is a separate model/classifier trained with human annotation. Here's a paper by OAI: https://arxiv.org/abs/2305.20050
6.
▲
by
dilyevsky
11d ago
That depends on the bylaws and specific contractual director-designation rights they may or may not have. Ianal but if he really controls 84% of shareholder votes like he claimed, he should be able to alter the board composition legally. Pr
7.
▲
by
dilyevsky
12d ago
If we’re comparing it to human thought process then there’s famously s1 and s2 thinking with former being more like looping in the latent space and s2 being more like cot. Personally im not convinced the way llm “think” is all that analogou
8.
▲
by
dilyevsky
12d ago
turns out that's not much cheaper and really limits design choices and sometimes house locations
9.
▲
by
dilyevsky
12d ago
wouldn't that imply some sort of "subconscious" reasoning ability that's hidden? and if that was the case why would we need cot in the first place?
10.
▲
by
dilyevsky
12d ago
> There really is no way to control them it seems like it should be feasible to analyze cot trajectories that lead to such behavior and punish them retroactively so not sure it's impossible but maybe someone just hasn't tried e
11.
▲
by
dilyevsky
24d ago
Ime it remains the best model for prototyping, sims, visualization etc throwaway scenarios. Just don’t look at the generated code if you just let it rip on the problem for hours ;) but that advice applies to any model unfortunately
12.
▲
by
dilyevsky
24d ago
Wouldn’t finding such bugs be considered advantageous? That is unless someone just yoloing the result directly to customer ofc
13.
▲
by
dilyevsky
26d ago
Are you aware of the syzkaller and how many bugs it still finds including in networking stack?
14.
▲
by
dilyevsky
26d ago
Yes, lots. Early spdy was vulnerable to CRIME attacks and so was TLS1.0 (and to bunch of other attacks). Kaminsky DNS cache poisoning is another one that comes to mind
15.
▲
by
dilyevsky
28d ago
Lmao that output genuinely gives me the creeps. What's you opnion vs. SGLang in this regard?
16.
▲
by
dilyevsky
28d ago
Even 25 years ago being “too online” - back then it was icq, livejournal, and forums - was already destructive as hell and always led to some pretty cringe outcomes. At least these days some people make a career out of it, back then it was
17.
▲
by
dilyevsky
1mo ago
Very poor analogy - information security has very few commonalities with ballistics (duh)
18.
▲
by
dilyevsky
1mo ago
how is the user being held hostage? you can redirect hide my email addresses to any domain
19.
▲
by
dilyevsky
1mo ago
First of all, web/api being down is not the worst case scenario - i didn't even notice this till late in the day. Secondly, even 1M qps at the edge is tiny amount of compute, what you have here is not a scaling problem it's a
20.
▲
by
dilyevsky
1mo ago
Yes, just absolutely crazy way of doing load shedding. > why does it take more than seven hours to just raise the minimum on the Autoscaler for HAProxy and let the workload scheduler evict workloads that are less important than, say, the
21.
▲
by
dilyevsky
1mo ago
What TP is talking about has nothing to do with workload preemption and is more of a variation of loadshedding (e.g overload management in Envoy). When I was part of the team that ran Google's clusters we had very few priority classes
22.
▲
by
dilyevsky
1mo ago
backoff is only applied to individual pods/containers not across pods. the point is at scale it's easy to get into a situation where it's not possible to recover without (usually manual) full service drain
23.
▲
by
dilyevsky
1mo ago
1. was already mentioned in sibling - cascade failures 2. you'll have massive number of restarts for various flake reasons and missing things that got papered over with restarts until you hit 1 and everything is broken. another popular
24.
▲
by
dilyevsky
1mo ago
article description is low on details but i don't think what you and OP are describing can be categorized as overfitting in the statistical sense and more like "reward hacking" by the model. like you said more likely than not
25.
▲
by
dilyevsky
1mo ago
on older PC bios would perform a memory test - you may remember those - and that's where it would mark a bunch of pages dead/unusuable and it was not uncommon at all.
26.
▲
by
dilyevsky
1mo ago
this reminds me how in the late aughts russian government tried to create some national, lib-free wikipedia version so what they did was rip entirety of wikipedia, deleted some articles and then search-replaced "wiki" with their n
27.
▲
by
dilyevsky
1mo ago
RS and XOR EC are definitely useful features for an object store that's storing from like tens of petabytes to exabytes worth of data but for a remote block device with a typical size up to a couple dozen terabytes I'm not so sure
28.
▲
by
dilyevsky
1mo ago
Slow, buggy and resource hungry. Faster spdk-based engine rewrite has been on the way for like 7 years now
29.
▲
by
dilyevsky
1mo ago
why longhorn and not mayastor? longhorn doesn't even have nvmeof that is not experimental
30.
▲
by
dilyevsky
2mo ago
For sure! I haven't had the opportunity to burn many tokens on this but given how quickly it was able to fuzz it into crashing i'm sure it can manage.
More ›