This is not the first time something like this has been done, Erik Ekman made PingFS, a file system that stores data in the internet itself .
This works because inside every ping packet is a section of data that must be sent back to the system that sent the ping, called the data payload.
Because you can put up to 1400-ish bytes in this payload, and pings take time to come back, you can use the speed of light in fiber as actual storage.
Now obviously this is not a great idea for long term data storage, since you have to keep transmitting and receiving the same packets over and over again, plus the internet gives no promise that the packet won’t be dropped at any time, and if that happens then the data is lost.
However. DNS has caches. It has caches everywhere.
Obviously, neither DNSFS, nor PingFS should be used for anything serious, but both are excellent experiments, demonstrating the flexibility of the TCP/IP and thinking outside the box.
You may see security alerts on your repositories as dependency graph support rolls out. When there’s a published vulnerability on any of the Composer dependencies that your project lists in composer.json and composer.lock files, GitHub will send you an alert including email or web notifications, depending on your preferences.
These now work for both public and private repositories, and repository admins can enable or disable the features as needed.
I’ve been using Google Chrome as my primary and only browser for years now. But this particular Firefox add-on – Firefox Multi-Account Containers – makes me seriously consider switching back to Firefox again.
Firefox Multi-Account Containers lets you keep parts of your online life separated into color-coded tabs that preserve your privacy. Cookies are separated by container, allowing you to use the web with multiple identities or accounts simultaneously.
This is pure gold for anyone who works with multiple accounts on any given site. Examples: Gmail, Facebooks, Twitter, Amazon AWS, and many more.
Google is sharing “How to do a code review” as part of its engineering practices. Unlike many similar guides online, I find this document to be a lot more comprehensive. It covers both the technical bits of the process, as well as suggestions that improve overall team communications and efficiency.
A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates mightneed to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.