Pinned Loading

1. bytebeamio/uplink bytebeamio/uplink Public

   Utility to receive commands from and efficiently send data to an IoT Backend

   Rust 44 10

2. Greed is in optimization, dynamicall... Greed is in optimization, dynamically incentivise to channel the greed for better

   1

   All systems tend to collapse, it is the order of nature after all. Greed is but a side effect of a collapsing system, one where ethics, i.e. rules and regulations are lax and the optimizations are focused on variables that are sometimes unimportant to the larger picture. This is not only because we as humans can't agree on infallible laws, but because the agreements themselves have an expiry period while the laws might not.

   2

   3

   Some of society's biggest mistakes have been in holding onto traditions and constructs that have affected it's ability to accept the realities of the times. What gibberish? Well, that is exactly what we see on a day to day, in how the herd tends to treat the "pioneers"/"witches". More than enough times, the innovators and radicals have given more to human progress and quality of life than what a few bad actors could have taken away.

   4

   5

   Take some time to understand these points and you will notice that quite often the answer to solving for greed is only in using it to our own advantage, i.e. only the greediest tend to win, by using the greed of others to compound their own gains. Greed is not wrong, it is part of the lived human experience, a survival instinct none the less. The challenge we face when building policy that truly accounts for greed is in tackling the optimizations that may override the checks and balances we can come up with, factors that just can not be foretold.

3. bytebeamio/rumqtt bytebeamio/rumqtt Public

   The MQTT ecosystem in rust

   Rust 1.6k 255

4. qrs qrs Public

   A client-side web app to generate QR codes, built with rust-wasm.

   Rust 4 1

5. Building dstore, a partially distrib... Building dstore, a partially distributed memory store

   1

   At the end of 2020 I had learnt a lot about programming in rust-lang and had worked on some large codebases, all while doing some interesting system implementations on the side. We had planned to implement our thesis project by the end of the academic year, but faced a lot of challenges in getting started, procrastination had hit us hard. By January I felt we had done enough experimentation and that we needed to do some "real" work, and hence got started on implementing a core piece of the puzzle, the partially distributed datastore, which consisted of a central server and multiple clients with the ability to cache values and check if invalidated.

   2

   3

   To do this, I had to learn gRPC, for which I figured out [Tonic](https://docs.rs/tonic/0.4.3/tonic/) would be a great place to start with, and thus, with the code that [@bkp31415](https://github.com/bkp31415) had written in proto3, I got started implementing what would be [the first iteration of dstore's gRPC API](https://github.com/vyuham/dstore/commit/727d56de80554db9ef16dff5f0c5e1e92d58e90e). An interesting DSL to learn, proto turned out to be quite a bit more coplex than we had anticipated, we will talk a bit about that later.

   4

   5

   Next, we had to implement the datastore, and to do that we had to write [a server implementation](https://github.com/vyuham/dstore/commit/fee252d14dc0c8a382a6331b345ca968c2053c9d). I was learning a lot about how Mutex locks work, I sure know a lot more now, but at that point I felt our application wouldn't worry much about having to wait a few seconds to get the lock while we were performing other operations on the datastore. Yes, at this point the datastore was built on top of a simple `HashMap<String, String>`, I was only trying to hold key-value data here, and this lack of complexity helped make things a lot simpler. Three RPC definitions were also made in this commit, and this is how dstore clients perform operations on the server, with `set()`, `get()` and `del()` being the most obvious name choices I had. Here, `main()` is basically hardcoded to run the server on `localhost:50051`, not much else to see here, maybe the cargo config files are slightly interesting, but we will get to that later.

6. vyuham/dstore vyuham/dstore Public

   A partially distributed storage framework, using the two-layer architecture, in-development.

   Rust 4 3