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.
Probably because a significant portion of HN readership already subscribes to the websites that commonly make it to the front page, and others know how to bypass the pay wall (i.e. https://archive.is/lk15F if you want to read this without a subscription).
I can't remember seeing any pay walled article on HN that wasn't bypassable using popular free services online. Usually, someone will also link one of the bypass websites pretty soon after a post starts gaining traction.
That the archive URL is some generally accepted thing here seems bizarre to me. I mean, taking the text and hosting it elsewhere—that’s just an unauthorized copy, just like if somebody had posted a torrent of a new popular movie so we could discuss it. Or links to cracked software (how else could those of us who don’t want to pay for it discuss it, right?)
I respond to the headline/other discussion in the thread if it is interesting. IMO, the publisher’s decision of how they want their work distributed and discussed should be respected. That includes not making unauthorized copies, and also the fact that that constrains conversation about their work.
I’m surprised that we seem to understand this for software but not written word. And we mostly act accordingly: lots of discussion of open source works, not so much on “paywalled” proprietary software.
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.
SQLite has a built in mechanism for loading extensions at runtime. The extensions themselves are just dynamic libraries. The main entry point for the extension is an init function that SQLite calls when the library is loaded. Within that init function, the extension can register a number of different kinds of functionality:
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
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.
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.