Which is published on a video streaming website run by one of the biggest tracking and data collection companies, which is used to pay for the creation of the video (in addition to ads embedded in the video itself).
Not a valid critique when dealing with an oligopoly (YT, Tik Tok, Insta, etc.). You use the platform or you get ignored. Using the platform to criticize the platform or other platforms like it is possibly the best use of the platform.
AI mode doesn't even search. I'll ask it to find a blog post or article that I remember reading recently. It often just fails to find it. But when it does, it'll mention the title and say to just go to the link to it. But it never gives me the link. This is a literal response I got from AI mode (with titles swapped out):
> If you search the term "<POSSIBLE_ARTICLE_TITLE>" or "<POSSIBLE_ARTICLE_TITLE>" on Hacker News or Google, you will find the exact write-up and the massive threads of founders sharing matching horror stories.
Of course, there are no threads on HackerNews for that if you search it. My response was to just google for me, and it links me to a random novel that doesn't even match the titles suggested.
Maybe this is silly: what about zero-width spaces or other hidden characters? Add them in post-processing, and the response quality doesn't degrade (though rendering etc. might be wonky).
Yes, it is silly. Stripping these is about as trivial as removing "this post was written by Claude" appended in plaintext. You could make a clipboard monitor that does this as soon as you CTRL+C, it's a 1-shot prompt. Not to mention that these wonky Unicode chars will break in every other program.
Stripping Anthropic's watermarking, however, is more difficult - probably about 2 prompts.
But your average joe won't "setup custom clipboard monitor to auto clip out whitespace". That's why Gemini still include its logo into generated picture even if it's trivial to crop it out
Ok, sounds like a watermark of “this post was written by Claude” is sufficient then. Or don’t add any at all - the average joe is that Canadian politician whose speech included “here is a more natural-flowing version of that section that sounds more like legislative speech rather than a series of short points.”
The real problem is false positives. One false positives is enough to make the whole thing dangerous. The results can't really be acted upon without risking defamation. If you admit that you redistributed someone else's copyrighted work to an AI company that never forgets, it's an admission of distributing copyrighted works.
The law should have at the very least required offline validation tools that cannot track or retain a copy of the documents being checked.
Yeah. I actually love Google Photos as a product. I just want Immich as a safety net in case Google ever feels like locking me out of my account on a random Tuesday.
I haven't really found a guide or discussions on how best to use Immich in this mirroring way. Admittedly, I haven't looked very hard. Setting up Immich is something that's been on my todo list for years now.
You can use https://www.photosync-app.com/home if all you want is a local backup. It has a killer feature Immich is still missing: encryption at rest of the photos.
I personally find it nicer to unlock my phone to decrypt (Face ID) then dealing with having to auth with my headless server. Is there a way to manage this without putting the keys for LUKS or similar somewhere risky? Main threat is someone stealing the NAS during a break in.
You can store the key in the TPM. If someone steals the NAS, they can only decrypt it if they continue running the exact same software, which you harden (e.g. disable password login from the TTY).
Or you can SSH in and type the key once per reboot.
I'd second this question. And I really mean that in a sincere way. Why is the choice of a random HTTP library in an SDK such an engaging topic of discussion here? Is there some context I'm missing?
When I first read the title, I assumed this was some fancy new protocol that extends HTTP or something. But it's just about an SDK switching one transitive dependency with a fork? And arguably one that should just have its functionality be part of stdlib?
This happens all the time. Yesterday, I ran into an especially egregious case.
I had Fable add a new subcommand to our internal CLI tool. I reviewed and tested it locally and had to suggest several fixes that I feel like I wouldn't have had to tell a human senior engineer to do. When it finally submitted the PR, I had it on a loop waiting a few minutes for comments on the PR, then assessing/addressing/replying-to/resolving them, and then repeating again until all AI reviewers were okay with it. It ended up going through dozens of revisions and ended up with 160 comments left on the PR.
OTel is so frustrating. If it wasn't shaping to be the clear winner in the space, I wouldn't complain about it as much. But today:
1. Every major vendor is still in some weird alpha/beta support for OTel even after all this time.
2. The performance hit is substantial and makes you question what the point of performance instrumentation is if you need twice as much compute/RAM to run the same workload now.
3. Serverless runtimes pay a heavy penalty for cold starts with OTel.
4. You're basically forced to run both gateway collectors and edge collectors for any realistic usage.
5. You still need to configure destination exporters in unique ways. This leaves you questioning what the value of OTel was.
6. Vendors that go beyond the scope of what OTel covers still need their own bespoke instrumentation. What was the point of any of this then?
> 4. You're basically forced to run both gateway collectors and edge collectors for any realistic usage.
You most certainly don't. You can run your app (especially if it's "serverless") without the collector agent.
App-to-agent and agent-to-sink use the same protocol, so all you need to do is set up the tracing/logging/metrics exporters to directly speak with the sink. These days, it typically means specifying the URL and the DSN header.
Perhaps there's a gap in my understanding. Can you clarify on this a bit more? I run a mix of serverless and non-serverless workloads.
Gateway collectors are unavoidable because various SaaS platforms require you to be running publicly reachable endpoints to send telemetry to.
In a runtime like Lambda, how would you avoid the need to run an edge collector? The only thing that comes to mind is to write to logs and then have a log stream processor that then writes to your gateway collector. Other than that, it seems unavoidable, no? Sure, in something like Fargate you could go app to sink. But even that has its own tradeoffs.
We use Node.js, so all we need to do is run a script initializing Otel before running the app. We set this up following the docs a few years ago, and haven’t had to change it much since then.
A typical setup is to run a separate OpenTelemetry collector process on the same host as the app. The app connects to it via localhost on a standard port (although you can override it using env vars).
The collector process then sends the metrics/traces/logs to the observability sink. But there's nothing at all preventing you from sending telemetry directly to the observability sink.
It's just outbound HTTP or GRPC, and it doesn't have to go over public Internet.
> In a runtime like Lambda, how would you avoid the need to run an edge collector?
Here's my setup (in Go, very simplified):
> // Instantiate a new slog logger
> logger := otelslog.NewLogger("root", otelslog.WithLoggerProvider(otelLogger))
> // Use the logger as needed
My code uses proper Go loggers exclusively. I also redirected the stdout and stderr to a goroutine (via the usual close(2)+open() trick) to serve as a catch-all sink for anything that slips the net.
If you're sending data purely to X-Ray, there's already a daemon running on lambda that you can forward to with low overhead if you don't use OTel. You also get near zero-cost logging and metric to Cloudwatch and EMF. But if you want bring destinations in the mix or do anything other than Cloudwatch , you have to pay the OTel tax. And even if you were content with a pure AWS setup, OTel is still being pushed on you now.
The X-Ray daemon and SDKs are all deprecated now in favor of OTel. Things like enchrichment of resource level traces for things like the DynamoDB client in v3 of the AWS JS SDK don't work with the X-Ray SDK. And they never will now. You're now recommended to use the AWS Distro for OpenTelemetry setup and OTel SDKs. The performance overhead of this is heavy, with big cold-start penalties.
Compare this with how the Datadog layer does adaptive flushing and performs relatively much better. Rotel is also promising in this space. But right now, OTel feels immature and things are being deprecated without the replacement being fully baked.
Because blocking on OTel data to flush before sending a response back is often unacceptable. The layers run a standalone process using the Lambda extension API so they can keep running after your function has responded to a request.
There isn't really a great alternative without vendor lock-in. If you go all-in on AWS Cloudwatch/X-Ray, it's a really easy setup with low effort. If you go all-in on Datadog, it's pretty easy. But if you want to mix Sentry, Langfuse, Datadog, etc, OTel is still probably the best option. It's just a letdown that this is the best there is.
I don't mean to disparage anyone working on OTel. I can appreciate that it has ambitious goals and it's not an easy problem to get alignment and interop here. Especially with all the stakeholders involved. But as a user, it feels simultaeneously over-engineered and under-engineered.
reply