3 overhead reading lights for a 2-2 configuration? On a trans pacific flight? Literally unplayable.
Would love to see this open source and extended!
674 karma · joined July 8, 2014
Would love to see this open source and extended!
fwiw it seems like “reduce white point” overrides any of these effects - which is good.
On international returns, both Global Entry or MPC lines are virtually empty when I arrive (SFO)
The worst part is international arrivals in foreign countries, where immigration can soak up a lot of time, and you have no choice but to stand in line. Luckily I don't have to fly internationally too many times a year.
> An NBER study of support agents [2] found generative AI boosted novice productivity by about a third while barely helping experts. Harvard Business School researchers found the same pattern in consulting work [3].
The first work cited was a research study on GPT-3(!) from 2020. Which is a barely coherent model relative to today's SOTA.
The second HBS research study literally finds the opposite of what's claimed:
> we observed performance enhancements in the experimental task for both groups when leveraging GPT-4. Note that the top-half-skill performers also received a significant boost, although not as much as the bottom-half-skill performers.
Where bottom-half skilled participants with AI outperformed top-half skilled participants without AI. (And top-half skilled participants gained another 11% improvement when pared with AI). Again, GPT-4 model intelligence (3 years ago) is a far cry from frontier models today.
Other times they would just link to real LinkedIn profiles, but the LinkedIn profile will say that they’re not actively looking and are a victim of id fraud basically.
It’s been a huge issue spotting candidates falsifying information since remote work took off unfortunately. They payout is if they can get at least 1 or 2 paychecks before being found out, they’ve made a good profit.
I hope to build some better visualizations down the line on model evolution instead of just hacking it onto the current scatterplot.
Slot machines on the other hand are truly random and success is luck based with no priors (the legal ones in the US anyways)
Improving LLM output through better inputs is neither an illusion, nor as easy as learning how to google (entire companies are being built around improving llm outputs and measuring that improvement)
- Reorder columns: You should be able to do so by modifying the order of the SELECT statement at the top.
- Wrapping: totally agree - this is something we're adding in, it's on the near term todos.
- Pin fields: you're totally right, you can pin values but that doesn't prioritize the filter in general. I'm getting this one in the queue.
- Time picker: I hear you with Google Cloud's time picker, they did indeed make a really nice one. Though I'm curious to hear more about the breakdown, is it wanting to customize how that chart is grouped beyond log level?
- Autocomplete: We had a regression if you're on v2.0.0 which is what I suspect you're hitting. If you're on v2.0.1 lucene should have field value autocomplete. We don't have it yet for SQL.
- Live View: Can you clarify what is scrolling? Or is this about disabling live?
- Chart View: I just tried really quick and it seems okay to me, do you mind sharing more details?
- Sidebar: Is this related to field popularity to pin fields or something else?
This feedback is all super helpful - you can probably tell we're still early in building out the perfect experience. I'd love it if we could dive in deeper either on our discord (https://hyperdx.io/discord) or email: michael.shi@clickhouse.com. Either way this has been exceptionally helpful :)
However, there's a bit of a fundamental difference in the user experience we're targeting. Grafana has really excelled at traditional monitoring dashboards, low cardinality monitoring workflows.
ClickHouse unlocks a newer paradigm of high cardinality, high performance observability. It enables a new set of workflows/UX that allows engineers to query novel problems quickly as opposed to working off of static dashboards. That's really a big focus of ours, so you'll see we do exploration/search/syntax/UI layout is quite different from Grafana due to this.
At this point it isn't even an original realization of ours. Just as an example, Shopify built a complete custom app (only keeping the auth part of Grafana) while migrating to ClickHouse for similar reasons.
But in this case there's probably no reason for you :) These improvements will come to our cloud offering of course as we work on rolling out upgrades from HyperDX v1 to v2 in cloud.
My take is that OTel is overall the best investment, it's widely supported across the board by many companies and other vendors. It's also constantly being improved with interesting ideas like otel-arrow which will make it even more performant (and columnar friendly!)
We'll also continue invest in the OTel ecosystem ourselves in making it easier and easier to get started :)
That being said, I'm not saying that OTel collector is always the right choice, we want to meet users where they are. Some users have data that gets piped into S3 files and we ingest off of a S3 bucket just due to how they've collected data, some use Vector due to its flexibility with VRL, focus on logs, or specific integrations it provides out of the box. So the answer is always - it depends :) but I do like OTel and think the future is bright.
Beyond raw performance and cost effectiveness, which is quite important at scale, we work a lot on making sure the application layer itself is intuitive to use. You can always play around with what ours looks like at play.hyperdx.io :)
Otherwise yes you can authenticate against the other versions with a email/password (really the email doesn't do anything in the open source distribution, just a user identifier but we keep there to be consistent)
HyperDX v2, the version that is now stable and shipped in ClickStack, focuses more on the querying layer. It lets users have more customization around ClickHouse (virtually any schema, any deployment).
Optionally, users can leverage other ways of getting data into ClickHouse like Vector, S3, etc. but still use HyperDX v2 on top. Previously in HyperDX v1 you _had_ to use OTel and our ingestion pipeline and our schemas. This is no longer true in v2.
Let me know if this explanation helps
We don't have any lock in to our ingestion pipeline or schema. Of course we optimize a lot for the OTel path, but it works perfectly fine without it too.
We have this on the medium term roadmap to investigate proper support for a compatibilty layer such as ferret or more likely just using ClickHouse itself as the operational data store.
Vector supports directly writing into ClickHouse - several companies use this at scale (iirc Anthropic does exactly this, they spoke about this recently at our user conference).
Please give it a try and let us know how it goes! Happy to help :)
- We're flexible on top of any ClickHouse instance, you can use virtually any schema in ClickHouse and things will still work. Custom schemas are pretty important for either tuned high performance or once you're at a scale like Anthropic. This makes it also incredibly easy to get started (especially if you already have data in ClickHouse). - The above also means you don't need to buy into OTel. I love OTel but some companies choose to use Vector, Cribl, S3, a custom writing script, etc for good reasons. All of that is supported natively due to the various ClickHouse integrations, and naturally means you can use ClickStack/HyperDX in that scenario as well. - We also have some cool tools around wrangling telemetry at scale, from Event Deltas (high cardinality correlation between slow spans and normal spans to root cause issues) to Event Patterns (clustering similar logs or spans together automatically with ML) - all of these help users dive into their data in easier ways than just searching & charting. - We also have session replay capability - to truly unify everything from click to infra metrics.
We're built to work at the 100PB+ scale we run internally here for monitoring ClickHouse Cloud, but flexible enough to pin point specific user issues that get brought up once in a support case in an end-to-end manner.
There's probably a lot more I'm missing. Ultimately from a product philosophy standpoint, we aren't big believers in the "3 pillars" concept, which tends to manifest as 3 silos/tabs for "logs", "metrics", "traces" (this isn't just Signoz - but across the industry). I'm a big believer that we're building tools to unify and centralize signals/clues in one place and giving the right datapoint at the right time to the engineer. During an incident I just think about what's the next clue I can get to root cause an issue, not if I'm in the logging product or the tracing product.
HyperDX isn't being deprecated, you can probably see on the marketing page it's still really prominently featured as an integral part of the stack - so nothing changing there.
We do of course want to get users onto HyperDX v2 and the overall ClickStack pattern. This doesn't mean HyperDX is going away by any means - just that HyperDX is focused a lot more on the end-user experience, and we get to leverage the flexibility, learnings and performance of a more exposed ClickHouse-powered core which is the intent of ClickStack. On the engineering side, we're working on making sure it's a smooth path for both open source and cloud.
side note: weird I thought I replied to this one already but I've been dealing with spotty wifi today :)
OTel Metrics: I get it, it's specified as almost a superset of everyone's favorite metric standards with config for push/pull, monotonic vs delta, exponential/"native" histograms, etc. I have my preferences as well which would be a subset of the standard but I get why a unifying standard needed to be flexible.
Statsd: The great thing about the OTel collector is that it allows ingesting a variety of different data formats, so you can take in statsd and output OTel or write directly to ClickHouse: https://github.com/open-telemetry/opentelemetry-collector-co...
We correlate across trace/span id as well as resource attributes. The correlation across logs/traces with span/trace id is a pretty well worn path across our product. Metrics to the rest is natively done via resource attributes and we primarily expose correlation for K8s-based workloads with more to come. We don't do exemplars _yet_ to solve the more generic correlation case for metrics (though I don't think statsd can transmit exemplars)
Elixir: We try to do our best to support wherever our users are, the OTel SDK and ours have continued to change in parallel over time - we'll want to likely re-evaluate if we should start pointing towards the base OTel SDK for Elixir. We've been pretty early on the OTel SDK side across the board so things continue to evolve, for example our Deno OTel integration came out I think over a year before Deno officially launched one with native HyperDX documentation <3
Notebooks: Yes, it should land in an experimental state shortly, stay tuned :) There's a lot of exciting workflows we're looking to unlock with notebooks as well. If you have any thoughts in this direction, please let me know. I'd love to get more user input ahead of the first release.
I've also been in touch with Mike & Ray for a bit, who've told me they've added ClickHouse support recently which makes the story even better :)