devdiary

No thanks

The original Raspberry announcement about Raspberry Pi Connect

> All devices get remote shell out-of-the-box, and if you use a Wayland compositor, such as Wayfire, you can also share your screen. In practice, this means you can use screen sharing with Raspberry Pi 4 and later models, and remote shell with all models of Raspberry Pi, even the oldest.

Now I have another task to purge this out of my pi.

And how do you measure the api latency? Any do's and dont's you have learned related to this metrics?

Start with usual session based authentication. Keep it until you see the absolute need to move to JWT. And make sure you understand JWT and "invalidating JWT" before using it - https://github.com/gitcommitshow/auth-jwt?tab=readme-ov-file...

> at the end of the day prompts are just a API call and it's easier to write standard code that treats LLM calls as a flaky API call

They are also dull (higher latency for same resources) APIs if you're self-hosting LLM. Special attention needed to plan the capacity.

Do not understand your comment. What are you trying to say?

thank you for sharing the archive link. Didn't know it is possible to archive a non-public/paywalled content.

How come a paywalled content gets to the top of the HN front-page?

Can you ELI5, how did you make this possible? I see the readme asking to download a binary and then also mentioning sqlite extension. I have never had exp with sqlite ext, so not quite sure how do they work. Appreciate how does this solution work under the hood.

And this understanding is extremely important when you are working on rate limiting. Instead of controlling the rate of requests, one must control the number of concurrent requests - https://docs.fluxninja.com/concepts/concurrency-limiter

Throughput (number of requests processed) is different from capacity (number of requests that can be handled). Managing capacity is more practical and optimum solution than managing the throughput

Thank you for writing this

I use the similar kind of structure in Developer Diary. I do it completely offline, no sync.

And yes, specifically talking about plugin based architecture. Not just a code refactor. Decoupling is the first step and the plugins will be created by internal team initially, the next will be to ensure security when external users publish their own plugins. The tech stack is Node.js.

I also face the same and I have set policy to ban such traffic by IP. Qq: How do you know the IP is forged?

A default glitch effect in the video can make the distortions a "feature not a bug"

The acquisition seems to be old, Y2019. I am not sure if you wrote this blog just now or had written earlier and published now. How have your perspective changed about the decision to get acquired since 2019, if it did?

I doubt it will be a huge success but this sparks interesting thoughts - how to put all these things on such a tiny board and power it up with a tiny Li battery. How to build it at home? FEMTO-ITX seems like the smallest motherboard to get started with. Is there a better/smaller alternative?

The plan to turn Pi into NAS moves to the top priority again!

Thank you for sending me down the rabbithole of RISC :)

how do you deal with token limitation? What is the maximus size of codebase it can work on?

Been there, done that

Amazing experience. Can't wait to see when this hits 1.0. What are the ways to avoid hitting the token limit?

It is not a question of "can" but "when"

While this articles point out all the right explanation on why telemetry is needed and how it can be made little more transparent by Go toolchain acting as intermediary and publishing the telemetry data publicly, it fails to point out the disadvantages/risks of such system. At the core, the issue is about trust and the user not having any incentive.

Had seen dvc almost 2 yrs ago. Is it enterprise offering of the same?

So cool. Similarly, can we also build clickhouse-remote?

That's what I meant to say - don't put your critical services passwords in one cloud password manager

Using "password manager for everything" comes with a critical disadvantages of making the pass mgr a single point of failure, increasing attack surface area. Take an example of recent Lastpass breach, I am pretty sure it will lead to hacking almost all services for some Lastpass users. Although Lastpass is saying - don't worry, your passwords are encrypted with your master password and it will take million yrs to crack them. No, it won't take even a month/day to crack master password of many of those users. You're overestimating people's ability to create strong master password and the efforts needed in cracking a password.

I'd rather be very specific in suggesting password managers, use them only for non-critical services.

Still learning. Anyone wants to attempt - Explain like im5 for this?

Interesting. What exactly do you mean by"concentration"?

What are your thoughts on the idea and the architecture presented in the article? Will headless CDP drive similar impact that headless CMS have brought?