Corbin

I might prototype a workflow with this tool, but I don't really have any problems that it would solve. Connectivity to my machines is established with overlay networks and isn't a problem; I'd rather read a Prometheus dashboard than connect to individual machines, and I'd rather sit back and know that everything is working within acceptable parameters and metrics than repeatedly probe parts of the system.

Some of the features feel like they can never be made secure; in particular, it's not clear how XPipe changes the threat model for attacks which start by compromising a single development environment, other than being a large obvious target. File transfer is another good example; every connection protocol either already has file transfer or it doesn't, and for two Internet-connected machines I can always fall back to Magic Wormhole. Similarly, while it's important to know how to get into a Kubernetes Pod, it's usually a security problem to have one-click SSH access to hundreds of them.

I'm telling you this mostly because of the open-core note. I genuinely cannot imagine recommending XPipe for purchase in any scenario, and I don't know how much that will change after prototyping a workflow. Shops that have needed tools for managing thousands of machines/sysadmin usually are willing to do the in-house development to build in-house tools. Over the past decade, GIFEE ("Google's infrastructure, for everybody else") has resulted in first Prometheus and now (I guess) OpenTelemetry making it possible to have good observability on tiny, small, and medium systems with a single observatory. It also shouldn't surprise you that I'm not going to recommend XPipe outside of a work context or encourage folks to contribute to it; there's no point in building a community around a closed project.

Yeah, writing your own squeeblerizer sucks, but there's no better option. GNU Scrimble can be used off-the-shelf as a passthrough, so the only real tasks are implementing Squeeb's algorithm and a sprongler; then, your entire pipeline is merely something like:

$ gscrimble --passthrough --args -- ./your_squeeb | ./your_sprongler

Edit: Whoops! Forgot to mention, GNU Scrimble also has Snorble support out-of-the-box, and Scrimble clients have content auto-negotiation, so your_squeeb can just take JSON on stdin. GNU Scrimble is really nice for this sort of thing, just...big.

And if you want to sprongle directly into a database or etc. then you can write your_sprongler to taste. Full disclosure: I have a fairly fast implementation of Squeeb's algorithm in rpypkgs. However, I'd really recommend writing your own; it's like twenty lines of code you can copy from Wikipedia and it'll give you a good basis for extending it with your own desired changes later.

You can read snorblite's code if you need to figure out a specific sprongling technique, but it's way easier to just go look up the original SprongCode from SprongReg. Use a search engine to get around the university's paywall. This gets you the SprongCode UUID and you don't have to read code written by a batshit fascist.

Can notifications be started from a systemd unit? Kind of. notify-send can be invoked from systemd, but getting the correct user notified is non-trivial and I'm not sure how it would be done on NixOS.

Can nixos-rebuild have a progress bar? Not really. It's not a process with a predictable end time.

Can there be notifications when updates are available? There are scripts out there (like this one which I have never used) which can poll git repositories and run notify-send, but that's not very useful. Instead, it's worth knowing that most of the cost of auto-upgrade is running the nixos-rebuild command at all, even if there are no available upgrades!

Instead, consider setting system.autoUpgrade.dates to a fixed time when you definitely won't use the computer, and also set system.autoUpgrade.persistent. This will run auto-upgrade on boot in the worst case.

Also, USB devices should not be disconnecting on every update. If USB disconnections happen under high load, check dmesg for possible hints; you may merely need to add an override to boot.kernelParams.

Here are some questions that I want to answer when evaluating a new chat app:

• How is it hosted? What is the network topology? Which Trent must be trusted?
• Has the cryptography been audited? What are the primitives and protocols used? What kinds of guarantees, aside from basic privacy, are actually established?
• What happens during a disaster? Am I easy to dox, track, etc.? What bad things happen if somebody takes my phone from me?

This looks like it took a lot of work, and I'm not dismissing it, but it's important to know that most of us are going to look at new chat apps by comparing them to what they already have. "P2P encrypted" doesn't sound like actual security.

It's because the Booleans sometimes are flipped in display-server technology from the 1980s, particularly anything with X11 lineage, and C didn't have Boolean values back then. More generally, sometimes it's useful to have truthhood be encoded low or 0, as in common Forths or many lower-level electrical-engineering protocols. The practice died off as popular languages started to have native Boolean values; today, about three quarters of new developers learn Python or ECMAScript as their first language, and FFI bindings are designed to paper over such low-level details. You'll also sometimes see newer C/C++ libraries depending on newer standards which add native Booleans.

As a fellow vim user with small hands, here are some tricks. The verb gU will uppercase letters but not underscores or hyphens, so sentences like gUiw can be used to uppercase an entire constant. The immediate action ~ which switches cases can be turned into a verb by :set tildeop, after which it can be used in a similar way to gU. If constants are all namespaced with a prefix followed by something unique like an underscore, then the prefix can be left out of new sections of code and added back in with a macro or a :%s replacement.

I was going to bring this one up. The least realistic part of Antitrust is how the antagonist is defeated, but the parts where somebody is impatiently waiting for javac to finish so that they can pack their .class files into a JAR, or typing in a list of IPv4 addresses one-by-one to see which one works, were painfully plausible.

In short: If you'd like to learn more, come visit #pypy on Libera IRC. It's an interesting discussion topic, particularly if we want standard-library imports like math, sys, or json to work.

RPython is not capable of translating to bare metal today; it depends on libc and libffi for many features even when not producing JIT compilers. It's also intended to operate on a layer of syscalls: rather than directly instructing hardware, it wants to make fairly plain calls, perhaps via FFI, passing ordinary low-level values. So, any OS developer would first have to figure out how to get RPython to emit code that doesn't require runtime support, and also write out the low-level architecture-specific hardware-access routines.

That said, RPython is designed to translate interpreters, and fundamentally it thinks an interpreter is any function with a while-loop, so a typical OS would be a fairly good fit in terms of architecture. RPython knows the difference between high-level garbage-collected objects and low-level machine-compatible values; GC would be available and most code would be written in a statically-typable dialect of Python 2.7 that tastes like Java or OCaml.

The OS would be the hard part. RPython admits the same compositional flexibility as standard Python, so it should be possible to hack PyPy into something that can be composed with other RPython codebases. This wouldn't be trivial, though; PyPy in particular is tightly glued to RPython since they are developed together in a single repository, and it wasn't intended for reuse from the RPython side.

If all of that sounds daunting, and what you would like to do instead is take an existing kernel or shell with C linkage and ELF support, and extend it arbitrarily using Python code, then PyPy can help you in that direction too. Compile a libpypy and embed PyPy against your kernel, and you can then run arbitrary Python code in a fairly nice environment which supports Python-first development. Warning: while the high-level parts of this might be nice, like Python's built-in REPL tools, the low-level parts could be very nasty since this embedding interface is old and rotting, to say nothing of actually getting bare-metal code that doesn't make syscalls.

A list can store zero or more elements. A NonEmpty can store one or more element. That's all.

This overall strategy -- representing the top of a list as a dedicated value -- shows up elsewhere, notably in Forths, where it is called "top of stack" and often stored in a dedicated CPU register.

Nah, you're just not good with maths. Programming languages are mathematical objects and denotational semantics is merely treating languages as categories and looking for functors leading out of them.

Semantics was originally studied as model theory, and today is phrased with category theory. You use this every day when you imagine what a program does in terms of machine effects.

Incorrect. The hidden gold is Factor. You were close!

Extension modules are implemented in C because the interpreter is written in C. If it were written in another language, folks would write extension modules for that language instead. Also, it would be less relevant if people used portable C bindings like cffi, which are portable to PyPy and other interpreters… but they don't.