Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
zeeg
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
31.
▲
by
zeeg
2y ago
I actually meant trace ID and parent event ID (and ID was inferred). Parent comment is correct in that trace ID isnt technically needed, and is in fact quite controversial. Its an implementation level protocol optimization though, and unfor
32.
▲
by
zeeg
2y ago
It is! But to prove your point, OTLP is actually just the transport protocol (Open Telemetry Transport Protocol). Its one of _so many things_ its trying to address. All of those things might be probems, but not everyone has those same probl
33.
▲
by
zeeg
2y ago
Just want to say I appreciate your stance. (also no one should feel like they have to contribute to our SDKs, but please file a ticket if somethings fucked up and we'll deal w/ it)
34.
▲
by
zeeg
2y ago
We’ll fund solving this as long as the committees agree with the goal. We just want standard tracing implementations. (Speaking on behalf of Sentry)
35.
▲
by
zeeg
2y ago
Yes! Its a bit deeper than that but its fundamentally a packaging issue.
36.
▲
by
zeeg
2y ago
Food for thought- the subjective nature of both of those is exactly why it shouldn’t be bundled.
37.
▲
by
zeeg
2y ago
It’s a bit deeper than that. The SDKs that library authors implement need to be extemely minimal. The collection libraries that vendors implement based on imo should also be minimal. OTLP imo doesn’t even need to be part of the spec. But mi
38.
▲
by
zeeg
2y ago
I totally agree I just wish we could do it in a way that doesn’t try to lump every problem into the same bucket. I don’t see what it achieves personally, and I think it’s limiting the ability for the original goals of the project to be as s
39.
▲
by
zeeg
2y ago
We just rewrote our most heavily used SDK to run on top of OTel. What do we gain from it failing? We also make most of our revenue from errors which don’t have an open protocol implementation outside of our own.
40.
▲
by
zeeg
2y ago
Author here. Y’all realize we’d just make more money if everyone has better instrumentation and we could spend less time on it, and more time on the product, right? There is no conspiracy. It’s simple math and reasoning. We don’t compete wi
41.
▲
by
zeeg
2y ago
So you’re saying it makes my thinking more clear? :) This is what happens when you use a tool designed for authoring code to also author content.
42.
▲
by
zeeg
2y ago
Author here. OpenTelemetry is not competitive to us (it doesn’t do what we do in plurality), and we specifically want to see the open tracing goals succeed. I was pretty clear about that in the post though.
43.
▲
by
zeeg
2y ago
Author here. That’s kind of making my point for me fwiw. It’s too complicated. I consider myself a product person so this is my version of that lens on the problem. I’m not dismissing the people problem at all - I actually am trying to sugg
44.
▲
by
zeeg
2y ago
The challenge with making statements like this is you're making them against not only the person who made the decisions, but also the person who holds 100% of the facts, and will openly share them. So lets talk about the facts, because
45.
▲
by
zeeg
2y ago
This is something we're (Sentry) not happy about. Always hard to maintain the simplicity with growing product functionality. There's efforts underway (e.g. https://github.com/getsentry/self-hosted/issues&
46.
▲
by
zeeg
2y ago
Where was the rug pull? The only people negatively impacted by Sentry's relicensing were people trying to monetize it. Did we negatively impact you? Anyone else in the community? Not that I've ever seen evidence of. Live and die o
47.
▲
by
zeeg
3y ago
Its literally described as open source all over. https://www.databricks.com/blog/announcing-dbrx-new-standard... Its even implied in comparisons everywhere: > Figure 1: DBRX outperforms established open source model
48.
▲
by
zeeg
3y ago
Did you read the post? I ask because based on that comment it sounds like you didn't. We have enterprise customers - you don't need artificial lock-in for that.
49.
▲
by
zeeg
3y ago
It looks as if this was published after the update, which you should take a look at if you haven't. That should answer some of your concerns. https://twitter.com/zeeg/status/1743384320637849652 That said: B)
50.
▲
by
zeeg
3y ago
Hard to tell as we always advertised with Syntax. I would say the investments are related, but not connected (and made independently). We love Syntax, believe in brand advertising, and wanted to push more thre. We also hate the CX of cookie
51.
▲
by
zeeg
3y ago
Agreed! There's some things we think customers won't care about, that we'd like to leverage in general (latency benchmarking for example), but not everything is that. Our current thought process is to support two additional c
52.
▲
by
zeeg
3y ago
Its not just simple logs at the end of the day, so there are two things to be aware of: 1. Logs will, no matter how well you do your job, contain something sensitive. Typically this ends up being customer data (PII). PII is the largest cust
53.
▲
by
zeeg
3y ago
David from Sentry- I just wanted to say that we've heard your feedback and are going to follow up. I'm not going to say we'll make any changes to the ToS, but there is at least a huge lack of clarity and clearly some triggeri
54.
▲
by
zeeg
3y ago
Let me circle back on the Vite issue. Bundles are the biggest challenge when doing this turns out :) Would you mind opening a GitHub so we can circle back there? Regarding .NET - it’s coming to all Sentry SDKs (even mobile!). They were look
55.
▲
by
zeeg
3y ago
In this case it makes sense: it’s a UI widget. We wrote the proxy also in Node just because you already likely needed JavaScript to install the UI component that it felt logical. Aside, 2019 and onward JavaScript has become the largest and
56.
▲
by
zeeg
3y ago
Don’t disagree, but technically the docs are in the same repo. Not easily consumed though. We removed bits from the readme as it kept becoming duplicated and eventually wrong. I think that’s the usual reason folks like to avoid it. DRY and
57.
▲
by
zeeg
3y ago
Yeah it absolutely could. Our docs aren’t great here and we may need to improve the APIs but it was important for us to not couple this to Sentry. The idea is that any data source could stream to the sidecar and at the same time consume fro
58.
▲
by
zeeg
3y ago
That’s a good way to think about it yeah. It’s not 1:1, and also can be extended beyond Sentry, but that was our MVP.
59.
▲
by
zeeg
3y ago
Both. Fwiw lots of folks have yet to invest in OTel so the market is super open. We’re also trying to adjust our approach to leverage OTels community instrumentation when it makes sense. That means that ideally you’ll be able to invest in O
60.
▲
by
zeeg
3y ago
What’s an example concern? It shouldn’t anymore than Sentry already does
More ›