Michal m93a

Note

This document is an RFC (Request for Comments), and should be treated as a suggestion to the community, and not as an actual standard. If you have any feedback, ideas or implementations you'd like to share regarding Structured Pipes, please feel free to drop these in the comment section below.

Structured Unix Pipes

An inter-process protocol that allows processes to communicate using structured data, much like Nushell's internal commands can. In order for a structured pipe a | b to work, the protocol must be supported by command a, command b, and the shell. The protocol is designed in such a way, that if either of the processes doesn't support structured pipes, communication reverts to ordinary (unstructured) Unix pipes.

Structured pipes pass data in a machine-readable format. Before the data start flowing between the two programs, the shell process asks them which formats they understand, and selects the the most prefered format supported by both.

S

Prompt

If one were to create a custom OS for a DIY microcontroller-based device (for example a cyberdeck or a feature phone), what unorthodox design decisions could they take to make to make the OS interesting from a computer-theoretical standpoint? Two examples that come to my mind are: designing the OS to be used on a heterogeneous set of cores, each having different performance and capabilities; and making all executables sandboxed via WebAssembly, with configurable privileges.

Response

Creating a custom OS for a DIY microcontroller-based device with unique and theoretically interesting design decisions can lead to fascinating and innovative results. Here are several unorthodox ideas you might consider:

1. Heterogeneous Core Utilization

As you mentioned, using a heterogeneous set of cores with different performance and capabilities can lead to interesting challenges and solutions:

Dynamic Task Allocation: Develop algorithms for dynamically allocating tasks to the most appropriate core ba

Articles

Specs

Clamped Value

Idealized syntax:

component ClampedValue {
  in min: number;
  in max: number;
  
  out value = clamp(min, prev value ?? 0, max);
}

	{
	"content_metadata": {
	"chapter_info": {
	"brandIntroDurationMs": 1532,
	"brandOutroDurationMs": 3204,
	"chapters": [
	{
	"length_ms": 15928,
	"start_offset_ms": 0,
	"start_offset_sec": 0,

	{
	"content_metadata": {
	"chapter_info": {
	"brandIntroDurationMs": 3924,
	"brandOutroDurationMs": 4945,
	"chapters": [
	{
	"length_ms": 22959,
	"start_offset_ms": 0,
	"start_offset_sec": 0,

	declare const Zero: unique symbol;
	type Zero = { [Zero]: true };

	declare const Succ: unique symbol;
	type Succ<T> = { [Succ]: T };

	type FirstElementOrZero<Arr extends any[]>
	= Arr extends []
	? Zero
	: Arr[0];

	[
	{
	"key": "ctrl+alt+o",
	"command": "runCommands",
	"args": {
	"commands": [
	"outline.removeView",
	"workbench.action.focusActiveEditorGroup"
	]
	},

	#!/usr/bin/env nu
	const p = ~/.bin/flatpak
	rm -rf $p
	mkdir $p
	(
	flatpak list --columns=application
	\| lines
	\| where (str contains "Platform" \| not $in)
	\| where (str contains "Gtk3theme" \| not $in)
	\| each {\|v\| [$"($p)/($v)", $"#!/usr/bin/sh\nflatpak run ($v)"]}

	function x
	nohup fish -c "$argv &" > /dev/null && exit
	end

	function x_complete
	set arg (commandline -ct)
	complete -C$arg
	end
	complete --command x --arguments '(x_complete)'