fenollp
Joined 13 years ago
Joined 13 years ago
Even these orders of magnitude are correct, this is still 14t-438t of material to process /per day/ just for one person.
I'm on this route myself, trying various things out at https://github.com/fenollp/reMarkable-tools
Handwriting (in and out) support is very important IMO. Also being able to draw DAGs.
I'd like an e-ink device with high frame rate and HW powerful enough to run some models locally or with good enough connectivity and sensors that e.g. Computer Vision tasks can be offloaded to the users' smartphone.
Feel free to expose your ideas on there :) I welcome Open Source discussion!
> Nothing in this diatribe argues that encryption at rest is creating a net negative, outside of it being represented as a be-all and end-all security measure. When I say encryption at rest is a scam, I’m talking about it from the eyes of the purchaser. And given that it’s their data at risk, this is the standpoint that matters.
It is packaged in the homebrew Toltec repo https://toltec-dev.org/
Some differences:
128 bit strongly generated payload (instead of 80 bits for ULIDs).
Only 32 bit time precision but that's wall clock time anyway.
Base62 encoded.
Not saying this would at all replace Harbormaster, but with DOCKER_HOST or `docker context` one can easily run docker and docker-compose commands without "ever logging in to the machine". Well, it does use SSH under the hood but this here seems more of a UX issue so there you go.
Discovering the DOCKER_HOST env var (changes the daemon socket) has made my usage of docker stuff much more powerful. Think "spawn a container on the machine with bad data" à la Bryan Cantrill at Joyent.
You mention different goals (from GA) and a will to open source (RK). The parent user seems to have found a way for you to publicize your business efficiently: a Starlark syntax on top of github actions through your runtime, maybe brought in by the OSS community, giving you ample opportunity to capt this market of developers.
People looking for better Developer UX would pay for faster processes, right?
Oh and long live Starlark and so long YAML.
And if any of this makes sense: https://fenollp.github.io/faster-rust-builds-docker_host
> Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier.
Are there slow-moving internal software at Google that relies on this nonce? This looks like the kind of thing that some clients will tend to rely on (for a reason yet unknown). That's how clients grow the standard in unintended ways, no?On another note:
3. optionally, the trailer field section, if present, sent as a single HEADERS frame.
I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume.I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.
It superseeds http_archive and falls back to git_repository if needed. Just run `bazel sync`. See it working at [1]. Note: there's an open (and somewhat long standing) issue WRT Bazel fetching from gitlab.
[0]: https://github.com/fenollp/bazel_upgradable [1]: https://github.com/voidstarHQ/voidstar/blob/master/WORKSPACE
Creator of https://fuzzymonkey.co
https://fenollp.github.io/
Maintainer of https://erldocs.com/
Traveling through https://github.com/voidstarHQ/voidstar
Look, I've merged Fuzzing and Property-Based testing: https://github.com/fenollp/coverage_targeted_property_testing#prop_03_coverage_targeted