What you want to do: You hire a couple which creates a company which buys the property. It then setups something like a hotel keeps everything maintained, creates a garden, food storage etc. etc. etc. and keeps a more hidden area of the house compeltly private.
When he wants to visit, he has the convidence that he is under full control, but no one would start investigating the property, no one would assume he lives there etc.
And it doesn't need to be maintained just because, which will lead to missuse, fraud etc.
He could do this around the globe and put some sustainability/renewable whatever story in front of.
And there are plenty of things you did not opimize for. Like making sure certain dimensions are already known to the dom renderer so that the layout doesn't jump around.
Or progressive images so that it doesn't just popup suddenly.
There is a huge difference between breaking partnerships by fast uni-directional policies vs. slow uni-directional or bi-directional policies.
EU and even USA should start doing something reasonable. Like introducing quota on how much overall can be imported/exported to protect local markets. Like lets say 40%.
Everyone gets a piece of cake.
But lets be honest, germany (my country) also never played fair. We gained quite a lot of export strength through the Euro and overall german politics.
And its not just the energy prices, it was quite clear what the energy prices going to be but no one really invested into reducing them early or fast enough at all. No one cared. BMW new factory in hungarie though does has a lot more reneablw and was able to continue production despite hungaries energy issue.
In China a person makes 500-1000 per month, in germany the same person makes a lot more.
China you have raw resources and cheap labor and cheap energy on EVERY SINGLE point of the process. From iron ore to the assembly itself.
And it doesn't matter much anyway because with the current and future grade of automatisation, a lot less money is getting directly to the people.
We need laws enforcing the rich to pay the taxes and/or invest A LOT more a lot faster and a lot broader.
We need real politics and not this garbage happening in germany or in the USA or in Russia.
Logs and metrics are both derived from events. A log takes the whole event and records it somewhere. A metric takes some numeric value from the event, aggregates it over time, and records it periodically. You can reconstruct a metric from logs for the underlying events.
A trace is a period of execution between two events. You could record a trace as a pair of log entries, or one log entry at the end. You can then reconstruct a trace from those log entries. If you want to associate multiple spans, and separate log entries, within a trace, you use a shared ID, which is just the same as a context entry for logging.
All three of these pillars are just ways of looking at events. They are not fundamentally different at all. This is a mistaken idea in "Observability 1.0" whose correction is the basis of "Observability 2.0".
The pillars still have their uses, but the choice between them is really a non-functional one - storing a log entry for every event might be too expensive, so just store metrics instead, and index every log entry so it can be correlated with nearby ones might be too expensive, so just store specific traces instead.
This is the literally the "everything is a graph" argument from database architecture. The conceptual abstraction fails badly because it has to be implemented on real silicon that imposes constraints not considered in the abstraction.
Logs, metrics, and traces are all derived from raw events but none of them are intrinsically discrete events in a systems engineering sense. They are all different data models with different patterns of traversal over raw events. As data model, you need to build secondary indexes over the raw metrics to reflect the orthogonal data access patterns depending on if you are evaluating them as logs, metrics, or traces. This famously has poor scalability and performance.
In analytical processing we largely manage the inherent performance and scalability issues using denormalization, which allows processing pipelines with very different requirements to be optimized independently. Or in this context, treating logs, metrics, and traces as unrelated things with independent infrastructure.
"Observability 2.0" deeply embeds an architectural assumption that all systems are small. It is not a tractable architecture in high-scale or high-performance systems.
Real silicon has a long history of destroying beautiful conceptual abstractions in software engineering.
You are conflating the challenges of ingesting and querying at large scale with the what the original comment is about, which is emitting them more easily.
I don't see them as separate issues. Emitting them directly runs into the inherently poor memory locality (and potentially concurrency) of trying to produce logs, metrics, and traces from the same underlying event data representation.
It is only "easy" if performance and scalability don't matter.
> Logs and metrics are both derived from events. A log takes the whole event and records it somewhere. A metric takes some numeric value from the event, aggregates it over time, and records it periodically. You can reconstruct a metric from logs for the underlying events.
No, metric is just value. Some are derived from events (like histogram/rate of given event duration) but others are wholly independent (like returning app's CPU/memory usage)
The app's memory usage is an aggregation of the alloc/free events. I think the original point was that all of the metrics, traces and logs are conceptually the same but for efficiency, we store less data in each place, not the full history. Personally, for the systems I work on, having an easy way to turn logs into metrics and vice versa, without deciding up front, would be a slight benefit.
Technically, you can use the same places in the code where you stop/start/fork traces to also be the places where you increment the counters/gauges, etc. Which I think the GP was alluding to when describing the micrometer solution. Similarly, you can derive metrics for log lines without having to emit the actual log lines.
Then separately you can have log levels or verbosity levels that control to which level you actually emit traces/logs and/or roll up metrics.
At that point you almost might as well just log everything. The decision logic is likely about as complex as just doing it. Then I suppose you have a watchdog task that fires off every, say, 15 minutes or an hour or something, looks at the collected data, and either decides to keep it or trash it while recording a tiny "nothing interesting" datapoint.
No... Adaptive sampling is a family of statistical methods to choose an appropriate decimation strategy for arbitrary events based on real-world occurrence distributions.
It can be applied to tracing, metrics, logging ("sampling") and profiling.
Even if its not intelligence, a LLM found a bug due to one error message, fixed it, created a PR and it solved it.
If an LLM is only able to do all of this after training on it and never achieving AGI, we already at the point were it is cheaper to teach one LLM one problem than teaching humans to do so.
Sooooo what does it matter if we do 99% of things a LLM can just solve as a 'advanced search engine'?
Btw. an advanced search engine is probably the worst comparision i have read so far.
A LLM is a latent space which is capable of a lot of things a search engine can't do. It can apply different type of patterns and flows onto data, it can combine these etc.
My 'advanced search engine' was just able to create a working PR for exactly what i wanted it to solve (fixing a bug) by analysing the bug, finding a valid solution then commiting the solution itself.
Are you sure you are not doing the same thing with other texts?
I started to skim a lot more text due to me having read a lot. Like in news article, i stoped reading the first paragraph because it repeats just what it was already written in the short subtext. Then there is the second paragarph which is used to have some historical view or whatever it is.
I am very good at skimming over text. Human-written text I can usually glean the gist from very quickly, and get to choose how much I want to glean from it: The closer I look, the more I find.
With AI-written text, it's almost the opposite: the closer I look, the less I find. It is so information-sparse.
I started skimming reports im required to produce quarterly snd annually. I designed them to provide novel information at start and end so I can update them easily.
The problem I encounter is both my memory is degrading, but since these reports are largely duplicative, knowing which version im remembering is technically impossible since theres so much overlap. The overlap is tge same problem as context poisoning.
Id been doing this for over a decade when i started working with a new engineer with a few years of experience and younger. I tried to explain how i set these docs up so they can be skimmed and you can update the specific facts needed. They exclaimed they would never skim and rewrite it all. There was zero way to explain how exhausting that will become as they age.
So theres certain a tension about how people and AI will generate documents.
Just because some Higher Ups in Stripe bought this, doesn't mean its that valuable.
It can easily be, that Stripe can just afford it and think that they are part of the big boys and thats just what companies cost today.
It could be that Stripe really really like the brand name and all the positive notion of it.
It could be that Stripe doesn't want to build this from scratch in a timefrime of 1 year or 2 because Stripe might be too corporate to be able to do startup stuff.
Stripe has quite a high motivation to leverage agents thoguh because they are preparing for Agents which will buy through stripe. They already provide the SKU backend and support the agent payment stuff.
