I hereby claim:
- I am jhiesey on github.
- I am jhiesey (https://keybase.io/jhiesey) on keybase.
- I have a public key whose fingerprint is BE0B 130C AC88 9590 3E69 17A1 366B 7B28 4C4D 672A
To claim this, I am signing this object:
dbus-send --system --type=method_call --print-reply --dest=org.gnome.OSTree /org/gnome/OSTree org.freedesktop.DBus.Properties.GetAll string:org.gnome.OSTree | grep -A2 "dict entry" | grep -v "dict entry" | grep -v ^--; |
I hereby claim:
To claim this, I am signing this object:
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c | |
index cb5ece7..3440789 100644 | |
--- a/drivers/input/serio/i8042.c | |
+++ b/drivers/input/serio/i8042.c | |
@@ -883,6 +883,8 @@ static int i8042_controller_selftest(void) | |
unsigned char param; | |
int i = 0; | |
+ return 0; | |
+ |
#!/usr/bin/env node | |
const test = require('tape') | |
const rimraf = require('rimraf') | |
const wrtc = require('electron-webrtc')() | |
// delete previous download cache | |
rimraf.sync('/tmp/webtorrent/22cf567cbca91d3cc0a338aff766f4ba90da21e9') | |
rimraf.sync('/tmp/webtorrent/7cf8e59b32fddc94d888896d1e43be990a809352') |
Fundamentally, choose a set of peers to visualize by ID
One of the problems of the current libp2p DHT design is that the DHT is treated as a monolithic component implementing roughly the Kademlia protocol, while trying to stay as decoupled from the rest of the system as possible. This means that, for example, the Kademlia routing table is completely separate from the peer store. Instead, we should take the ideas from Kademlia (and subsequent research) and integrate them as appropriate throught libp2p. That doesn't mean that the core of the DHT isn't a modular component that can be omitted. It just means that useful functionality consumed by the DHT should be designed into the rest of the system.
Most of the nitty gritty details aren't yet defined; instead, this proposal is intended as a starting point for discussions. It assumes that the rest of libp2p exposes a quite different set of interfaces than is currently the case. Although the hope is that libp2p would eventually expose these different interfaces, it is feasible to build a shim underneath this
At the very lowest level of abstraction, streams are a natural representation for data traveling on a wire. They represent the continuous flow of bits (or symbols) streaming over a communications channel.
However, as soon as data enters a computer, a CPU must handle it, which involves a call to a handler. So, in a computer, a call that handles a block of data is the lowest level primitive. Streams, as currently defined in libp2p, are a higher level abstraction consisting of some state and an interface of calls. These streams have a number of complex properties that depend on underlying transports, and may or may not be desirable:
#!/usr/bin/env python3 | |
import serial | |
import struct | |
import sys | |
if len(sys.argv) < 2: | |
print(f"Usage: {sys.argv[0]}, <serial port>") | |
sys.exit(1) |
➜ wormhole git:(master) ✗ DEBUG=pw:protocol node | |
Welcome to Node.js v16.9.1. | |
Type ".help" for more information. | |
> const { webkit } = require('playwright'); | |
undefined | |
> | |
> (async () => { | |
... const browser = await webkit.launch(); | |
... const page = await browser.newPage(); | |
... await page.goto('https://wormhole.app'); |