fenollp

> The asteroid mass needed to support one astronaut for one year is between 160 000 metric tons and 5000 metric tons.

Even these orders of magnitude are correct, this is still 14t-438t of material to process /per day/ just for one person.

Yes!

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!

What do you mean by "adding rootless"?

From the article:

> 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.

I love seeing work in this space! I made a collaborative whiteboard app for the reMarkable a while ago: https://github.com/fenollp/reMarkable-tools

It is packaged in the homebrew Toltec repo https://toltec-dev.org/

ESC freezes it on Chrome on Linux.

We use K-Sortable Globally Unique IDs: https://github.com/segmentio/ksuid

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.

> I needed something that would manage all the containers without me having to ever log into the machine.

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.

Here's the video with timestamp https://youtu.be/kIFjDV_zHaQ?t=1168

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.

Then you'd be interested by https://github.com/denzp/cargo-wharf And DOCKER_HOST, and BuildKit!

And if any of this makes sense: https://fenollp.github.io/faster-rust-builds-docker_host

While this seems good to have a more efficient transport, I can't make sense of this

    > 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.

If you want to upgrade your Bazel dependencies using pinned semver constraints and a lockfile I've made this [0] for you.

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

From a quick look this looks like a subset of what https://repl.it/ provides (which is fine!).

Any features / wild ideas you feel deserve more attention than a quick look?

Acoustics is such a high dimensional medium yet one humans can readily manipulate... This reminds me of [1] (2016), where they optimize a 3D series of conduits so that they produce the desired output signal (given object shape and output audio frequency).

I wonder if one can arrange such conduits (6-way connected pipes and chambers) to replicate a feed forward neural network. If it can be done with light...

These pipes could be interesting to work with, maybe in order to build DAGs. Plenty of software take DAGs as an executable input! Can someone put me in contact with the people at [dynamicland]?

[1] https://www.youtube.com/watch?v=7JbN9vXxGYE

[dynamicland] https://www.dynamic-land.com/

Maybe going a bit off tangent here but really let's all agree that Dockerfile.s are just not good enough for building any kind of software through time. There's no lockfile system and caching is just awkward to work with.

Dockerfile.s must be progressively replaced with Nix recipes then we'd get lockfiles, upgradable dependencies, some day even reproducible builds!

Were any thoughts given to a process dictionary implementation? One (maybe supervised) process per instance of the pd_ordset type. The process would only ever have one client so no locking needed. Only potential issue would be the cost of sending messages. I have seen this kind of solution bring 100x speed improvements to write once <GB strings storage over ETS tables. This could be a gen_server as well. I’m curious because the PDict is often frowned upon (especially vocalized on the mailing list) yet cannot be avoided in some parts of OTP.

Also looking at the code leads me to believe the benchmarking of the rust code was done without taking the usage of a NIF’s overhead, if there is any. Is this intended or am I missing something?

Last question: are the great tracing capabilities of the BEAM lost when using NIFs and would this be an issue at Discord scale?

Thanks for the interesting write up.

Could we see a comparison with both `-ldflags '-s -w'` and `CGO_ENABLED=0`?

I feel like this would solve:

> the Go standard library is not well modularized; importing just one function (fmt.Println) pulls in about 300KB of code.

Points for helping against monopolies. I have been following the project for some years and am very happy to see it grow and on top of a functional front end at that!

Now where is Futhark's GEMM implementation & the vs. CuDNN benchmarks?

IMO Erlang needs Elixir’s `|>` and `with` pipes. I voiced my opinion on the ML and kind of started working on it! I need https://bugs.erlang.org/plugins/servlet/mobile#issue/ERL-639 fixed first.

I find Erlang a harder tool to shoot yourself with than Elixir yet there are definitely some things it could improve on, and not only at the language level (always running xref on compilation would be nice).

> Some crypto funcs now randomly read an extra byte

Can someone explain how this is a feature?

Soooo any way this can help run OS X in docker?

I wonder what this can mean for fuzzing, optimization, learning or any kind of task that has to do with tip-toeing into potentially high dimensional spaces?

echo -n is not POSIX. Use printf '%s\n' "$var" instead.

There's also "An Industrial Application of Mutation Testing: Lessons, Challenges, and Research Directions (2018)" by the same authors: https://ai.google/research/pubs/pub46907

So why a new spec format when there’s already OpenAPI, API Blueprint, RAML, ...? Is it just to support GraphQL?

I hope it's the last Terry Gilliam movie that's ever becoming true! (Brazil, 1985)

Code is at https://github.com/w8rbt/blooming_password but is private/404 right now.