Я уже писал про свои эксперименты с WebAssembly/WASI, недавно даже подкаст-монолог про это дело записал. Словом, я за темой слежу, причём слежу именно за направлением "универсальных бинарников".

А тут такая новость: Mozilla, Intel, RedHat и Fastly создали Bytecode Alliance — сообщество по пилению того самого нового формата бинарников.

Суть: реализовать возможность запускать универсальны WASM-бинарники в защищённых окружениях на разных системах и при этом управлять а) зависимостями и б) доступом зависимостей к системным ресурсам. Пункт "б", ИМХО — самый интересный! Можно взять стандартную библиотеку работы со строками (ага, leftpad) и запретить ей доступ ко всему, кроме, собственно, работы со строками!

Fastly регулярно пишут про свои эксперименты с Rust/Wasmer и им очень интересна вся эта тема с управлением правами wasm-бинарников. FastlyLabs открытые проекты по теме пилят. Словом, прямой коммерческий интерес к такому применению Wasm уже есть. А это очень важно для выживания технологии!

Отдельно радует роль #rust в около'wasm'овой экосистеме: на нём и рантаймы пишутся и инструментарий вроде wascap. Не говоря уж о том, что Rust — один из первых языков, начавших прорабатывать компиляцию в Wasm.

Ждём, надеемся, держим руку на пульсе #wasm :)

​​Так уж случилось, что я тут веду очные занятия по "основам типизированного ФП", в качестве учебного языка использую, как водится, #haskell. На днях мы прошли монады и написали библиотечку парсер-комбинаторов. На очереди Transformers, robots in disguise… ой, не эти, а обычные ("monads in disguise"?).

Изначально записалось аж тридцать человек(!), десятка два начали ходить, сейчас ходят 8-10. Один ученик в своём блоге о занятиях даже заметку написал — приятно! А вот домашние задания делают не все, поэтому приходится разбирать оные на самих уроках…

Зато потихоньку нарабатываю методтички (Literate Haskell + PDF) — пригодятся для будущих сессий!

(на картинке находится акроним TFPB, от Typed Functional Programming Basics)

​​Я почему-то всегда думал, что я уже писал здесь про Propeller и саму контору Parallax. Оказалось — нет, не писал. Восполняю пропуск!

Есть такая фирма, Parallax. Занимается разработкой своих линеек микроконтроллеров, а также наборов для обучения робототехнике.

Эпоха Stamps

В 199х Parallax была известна своими BASIC Stamp — это такие микроконтроллеры, которые работают под управлением специализированной версии #BASIC. Каждый контроллер выглядел, как 24-ногая микросхема (на самом деле это была маленькая платка), которая для работы требовала только батареи на 9В. Достаточно высокоуровневый, язык PBASIC позволял управлять множеством видов периферии, код загружался в ППЗУ по последовательному порту (позже через USB2UART), а ведь до Arduino оставался ещё десяток лет! Платформа была достаточно популярна тогда, но имеет своих почитателей и сейчас.

В 1997 году Parallax запустили образовательную программу "Stamps in Class", которая знакомила учеников с микроконтроллерами, основам разработки программ и электронных схем. Ученики даже программировали роботов Boe-Bot (один из самых популярных продуктов Parallax), имеющих BASIC Stamp 2 в роли "мозга".

Что интересно, по началу BASIC Stamp и BASIC Stamp 2 делались на баже микроконтроллеров PIC, которые устанавливались на ту самую плату-сборку, имитирующую DIP-корпус. Позже Parallax начали применять свой собственный PIC-подобные контроллеры Parallax SX, и продолжали применять до 2009г, когда чипы были сняты с производства.

В 2002г Parallax сделали смелый шаг — выпустили Javelin Stamp. На этот раз "почтовые марки" предлагалось программировать на Java! Да, это была урезанная версия и языка и платформы, но всё равно это было впечатляюще!

А потом в 2006г stamps наконец перешли на Parallax Propeller и язык Spin. Об этом в следующем посте <музыка из JoJo>

​​(продолжение предыдущей записи)

Эпоха Propeller

Propeller, это уже полностью детище самой Parallax, микроконтроллер с процессором 32-битной RISC-архитектуры, имеющим восемь ядер (2006г, напомню!). Программировался контроллер на своём ассемблере, а также на отдельном языке Spin — всё это, а также IDE для Spin разработали сами Parallax!

Для чего же микроконтроллеру восемь ядер, спросите вы? Ответ на этот вопрос и делает Пропеллер таким интересным! Дело в том, что Propeller не нёс на своём борту выделенных аппаратных шин, вроде UART, SPI и i2c: вместо этого предлагалось реализовывать соответствующие шины программно и поручать их обслуживание отдельным ядрам! Даже вместо прерываний и таймеров предполагалось использовать именно отдельные ядра. Потенциальные возможности поражали, ведь получился "почти ПЛИС", только программируемый на процедурном языке: представьте, что вы можете сделать контроллер с семью последовательными портами (одно ядро будет таки выполнять вашу программу) или что-то вроде "3 SPI + 2 TWI + 2 Dallas 1-wire"!

Кроме того, разные ядра могли по-разному тактоваться, что сильно упрощало формирование видеосигналов разных форматов. Или, скажем, цифрового звука.

Ввод-вывод был организован через один общий 32-битный порт со специальной подсистемой, защищающей от конфликтов при совместном доступе. Каждый из 32 пинов мог выдавать ШИМ!

Сам Spin был высокоуровневым языком, компилирующимся в байткод, который и выполнял Propeller на отдельных ядрах (их называли Cogs) — по интерпретатору на ядро. Язык использовал отступы для обозначения блоков, в коде допускались ассемблерные вставки.

Со временем появились компиляторы для C и PropBASIC (специальный диалект для Propeller), пара реализаций #Forth и прочие менее успешные поделки вроде подмножеств Pascal и Java.

Увы, железка получилась слишком уж специфической: для новичков она была сложна (трудно в голове уложить восемь программ), а для промышленности — слишком необычна. К 2010ым производство свернули.

В 2014 Parallax открыла под GPL 3.0 как всё ПО, так и всё "железо": код интерпретатора Spin, сред разработки, Verilog-описание процессора, HDL-файлы для обвеса. Так что Propeller 1 теперь полностью открыт. Хотя бы это радует!

Parallax тогда же объявил, что теперь они занимаются разработкой нового Propeller с производительностью 200 MIPS/Cog (вместо 20 MIPS на ядро у Propeller 1). Но я не знаю, в каком состоянии сейчас проект находится :(

Вторая жизнь Propeller 1

Так как платформа открыта, энтузиасты воплощают её в том или ином виде на FPGA. Есть и коммерческие реализации. Например, Soft Propeller от Trenz-Electronic — реализация Propeller на базе Xiliz Zinq (я как-то писал про Pynq — ПЛИС из этого же семейства, программируемый на Python). Что интересно, Soft Propeller физически совместим со старым "пропеллерным" железом: платка с ПЛИС, выполнена в том же формфакторе Narrow DIP, в котором выпускался оригинал, и может быть просто вставлена на место старого чипа! Люблю такое!

Давненько не писал. Будем считать, что был в творческом отпуске. Буду навёрстывать!

​​В прошлый раз я писал про #propeller, поделюсь ещё одной интересной штучкой с пропеллером!

К DEFCON'22' (DEFCON — это такая конференция для технарей) бейджики готовили сами Parallax. И, конечно же, бейджики были сделаны на основе Propeller! Тут можно почитать подробности. А я пройдусь "по верхам".

Каждый бейдж имел на борту помимо пропеллера ещё и ИК-трансивер (приёмник + светодиод), восемь светодиодов и четыре сенсорные кнопки. Ну и USB, конечно. При этом каждый бейдж был ещё и полноценной dev board для пропеллера: все порты были выведены на пятачки для пайки. ИК-трансивер был рассчитан на общение бейджиков между собой(!). Участники конференции обменивались таким образом контактами — забавно, правда? С эстетической точки зрения бейджи были тоже очень хороши: фигурные платы в разных цветовых схемах (фото прикреплю ниже), прям глаз радуется. Что интересно, именно на DEFCON'22 параллаксовцы официально объявили об открытии "исходников" Propeller — Verilog, схемы, вот это всё.

Но про бейдж DEFCON'22 я узнал, исследуя интернеты в поисках информации об этой прелести! Это тоже бейдж на пропеллере, но с OLED-экраном, тем же беспроводными средствами связи (ИК), и тоже представленный в нескольких цветах (разные цвета для персонала конференции, и для гостей). Пока я нашёл только эту заметку, в которой авторы делятся своим видением будущего устройства. Буду искать дальше, очень уж интересно.

​​В прошедшие выходные добрался таки до Pollen — системы для написании/программирования книг, построенной на базе #racket.

Racket я использую давно и знаю, что документация к языку и пакетам написана на отдельном диалекте Scribble, как уж это водится у "рэкетиров". И даже о Pollen я давно был наслышан — на Pollen "написана" отличная книга "Beautiful Racket" (а ещё "Practical Typography").

Pollen умеет обрабатывать Markdown и генерировать на его основе HTML, но может быть использован и в других сценариях. Самое интересное в системе, это специальный язык X-expressions — описание дерева документа, пригодное для дальнейшей обработки.

Так, все входные форматы сначала преобразуются в X-exps, а уже потом перегоняются в тот же HTML. Даже Markdown может быть преобразован в X-exps и дообработан программно перед преобразованием в HTML. И конечно же, обрабатывать X-exps и даже формировать можно с помощью Racket — Pollen является его надмножеством.

Подкину коду для демонстрации:

#lang pollen

◊(define who "World!")

◊div[#:class "content"]{
  ◊h1{
    Hello ◊|who|!
  }
  ◊strong{text}
}

"Ромбики" являются началами команд. S-exps являются Racket-кодом, а другие описывают разметку. Разметка при этом не выполняется, она просто записывается в X-exps как есть. А если учесть, что X-exps, имеет вид (div ((#:class "content")) (h1 () "Hello " who)) то вы можете догадаться, как Racket обрабатывает разметку и генерирует её сам :)

В конце итоговое X-exp скармливается шаблону, который превращает разметку в текст выходного формата. Причём выходных форматов может быть несколько! Книгу, скажем, можно преобразовать в HTML, а можно и в LaTeX/PDF.

При этом обрабатывает Pollen проекты по-взрослому — кэширует, раздаёт встроенным сервером контент (формирует контент налету).

Я на всём этом добре решил сгенерировать страничку для моей VDS с хобби-проектами. Получилось что-то такое: recursive.one. Контента, как обычно для меня, нет. Но сам "движок" писать мне понравилось :D. Как и в прошлый раз, когда я на #haskell и Shake движок написал.

Забыл написать, что этот свой Pollen generated site я запихал в #docker контейнер с lighttpd, чтобы самораздавайка получилась.

А контейнер задеплоил на VDS, на котором Dokku бегает — такой вот PaaS у меня для микропроектиков. Вот только heroku-style deploying через гит я не люблю, да и Heroku CLI мне не особо нравится. Поэтому загружаю образы целиком через docker save | ssh ... — для моих поделок на "не самых популярных стеках" самое то. Уже успешно "задоккивал" проект на #Clojure, Web-приветмир на #Racket.

Кому-то это всё покажется детскими играми. Но я не умею в этот ваш DevOps современный да и не очень-то и хочу уметь. Из современного освоил только Docker, а вся автоматизация на Makefiles сделана — не могу в k8s, зато могу в GNU m2e! И мне норм :)

Попробую новый экспериментальный формат: "Смотрите, какую дичь я писал когда-то", то есть "мои #old_projects".

Увы, в здесь нельзя вставлять изображения посреди текста, а поднимать заново движок для блога я пока не готов. А в Medium публиковать не хочу. Поэтому напишу серию постов — формат получается вдвойне экспериментальный.

Я, как настоящий самоучка, аж до моей второй работы варился исключительно в собственном соку. Учась в институте, я делал все свои проекты на Delphi, который изучил по его же встроенной документации, а дополнял знания из .CHM-книжек "Kuliba3000" (а может 4000, я уже и не помню) — был такой "самиздат" сборников статей из интернетов, прикладывался к дискам "сколько-то-там компонент для Delphi". Интернета у меня не было курса до третьего, так что на этом, собственно, мои источники информации и исчерпывались. Это к концу учёбы я добрался до интернета, форумов, Хабра. И узнал, что на Delphi писать зазорно. Ну да ладно, пост не об этом.

То, что я писал на QBASIC и TurboPascal в школе, увы не сохранилось — померло то ли на одном из старых "винтов", то ли на старых же дискетах. Этого вашего Git тогда ещё не было, а без интернета я бы всё равно не смог бы его использовать. Чудом сохранились лишь мои студенческие Delphi-поделки. Про одну из таких я и хочу рассказать.

​​Часть 1

Задумал я как-то написать движок для "point&click" квестов. Да, сразу движок. Потому что я откуда-то знал, что игры делают на движках, а не хардкодят каждый экран. Об анимации и визуализации персонажа я в принципе не думал. Предполагалось, что игры будут "от первого лица", как в "7th Guest" (ага, oldschool!). Был намечен абсолютный минимум: кликабельные объекты на экране, имеющие всплывающие подсказки, какой-то инвентарь, возможность изменять часть сцены (то есть наложение объектов на фон).

Нарисовал я пару экранов в XaraX, и начал думать, как бы разметить объекты сцены. В итоге выкрутился так: сделал невидимое изображение в 16-цветном .BMP, подложенное под изображение сцены. Позиция мыши "прокалывала" холст и я мог получить цвет задника. Цвет и был идентификатором объекта. 16 цветов, это 16 объектов — для одного экрана достаточно. Зато объекты могли состоять из нескольких областей и вообще иметь произвольную форму. А самое главное, я эту цветовую карту мог очень просто выгружать: я просто делал равномерную заливку в векторе, убирал сглаживание и экспортировал в .BMP. Этот формат использовался потому, что Delphi мог читать такие файлы самостоятельно и сжатие не вводило новые цвета, то есть не портило мне разметку.

Самый первый экран выглядел так:

​​Часть 2

Движок мой подразумевал то, что я скомпилирую его один раз, а ресурсы конкретной игры будут загружаться при запуске. А значит нужен был какой-то формат описания сцен, переходов, активностей. Выбрал я, конечно же, INI-файл — "искаропки", пишется в любом редакторе, секционность подходит для постраничной игры.

Имя секции соответствовало имени файла (его базовой части) изображения фона — вот вам "convention over configuration"! Первая сцена имела фиксированное имя "begin", соответственно подгружались файлы "begin.bmp" и "begin_m.bmp" — второй, это "маска", то есть тот самый невидимый слой с выделенными цветом объектами.

В секции писалось что-то такое:

[begin]
00FF00=j{waystone}
00FF00_h=Путевой камень
FF00FF=m{Бедный Ёрик}
FF00FF_h=Череп
FF0000=j{pogost}
FF0000_h=Дорога налево
FFFF00=j{rockwall}
FFFF00_h=Дорога направо

При перемещении мыши брался текущий цвет подложки, по нему как по ключу, доставались действие по клику и hint (всплывающая подсказка) для объекта: в примере эти ключ в формате RRGGBB и он же, но с суффиксом "_h" (hint). С текстом всё понятно, а действие "j{pogost}" означает "перейти(jump) к секции pogost".

Ключи секции, имеющие префикс "#", описывали "спрайты", то есть накладываемые на подложку объекты. Имя ключа (без префикса) служило именем файла, а значение было числом, которое в формате "640 * y + x" кодировало позицию спрайта относительно верхнего левого угла. Ага, тут я поленился вводить раздельное кодирование координат ;). Если же значение было меньше нуля, то спрайт не рисовался — так можно было показывать и прятать спрайты.

Вот вам спрайт дерева, которое рисовалось поверх пенька на стартовом экране (смотрите предыдущий пост).

Часть 3

Использование координат спрайтов, а точнее — их изменение, это уже попахивает переменными! Да, таковые я тоже предусмотрел. Даже секцию "vars" завёл, которая инициализирует все переменные игры. Переменные имеют префикс "$", могут встречаться в роли значений, а в секции "vars" в роли ключей. Тут всё понятно и просто.

Но переменные нужно изменять. Для этого я прикрутил целый мини-DSL. Тот самый "j{…}", упомянутый ранее, это команда языка как раз. Изменяла переменные команда "s{$x=y}" — тут тоже всё очевидно, надеюсь.

Ещё язык содержал предусловие, которое позволяло продолжить выполнение сценария только при наличии в инвентаре игрока нужного предмета. Парой для этой команды выступала команда, добавляющая в инвентарь предмет.

Предметы кодировались цифровыми идентификаторами, но по сути могли быть любыми валидными ключами: каждый идентификатор был ещё и ключом секции "invnames", значения в которой содержали имя предмета:

[invnames]
001=Ворота (украдены на кладбище)
002=Топор (взят в Пещере Гоблинов)
003=Дубовое бревно

А вот так выглядело срубание дерева на стартовом экране:

00FFFF=i{002}g{003}s{$tree=-1}.M{Вы срубили топором дуб и сделали из него бревно}
00FFFF_h=Сухое дерево (Дуб)
#tree=$tree

- "i{002}" — если есть "топор",
- "g{003}" — дать "бревно",
- "s{$tree=-1}" — присвоить переменной $tree значение -1, то есть спрятать спрайт дерева,
- "." — перерисовать сцену (максимально лаконично!),
- "M{…}" — показать message box с указанным текстом.

"#tree=$tree" помещает спрайт дерева туда, куда указывает переменная. При перерисовке сцены переменная читается каждый раз, поэтому изменения и вступают в силу. Так на картинке первого экрана и появляется пень — просто пропадает дерево, выводимое поверх него!

Команды языка пишутся без каких либо разделителей потому, что INI-файлы не предполагают многострочных литералов. Такое вот творчество в условиях ограничений :)

Часть 4

Язык сценариев получился вполне себе выразительный — для данной задачи, конечно же. Можно было описать довольно сложные сценарии.

Например, в игре вы шли на кладбище, брали там ворота (дверцу калитки), шли с ней к пещере со рвом перед входом, перекидывали калитку через ров на манер моста, и попадали в пещеру. Тут вам и взятие объектов и выбрасывание ("d{id}"), условные переходы, опять же.

В пещере вы получали топор, возвращались назад, рубили дерево, шли опять к пещере и заменяли калитку на бревно, чтобы использовать саму калитку позже! Тут использовались сценарии, хранящиеся в переменных — до экранирования я не догадался, поэтому копировал код из одних переменных в другие, вместо того, чтобы записывать код в "обработчики клика".

С технической стороны всё получилось максимально прямолинейно. Парсер DSL у меня был однопроходный — просто посимвольно обходил строку однократно, сразу же выполняя команды. Никаких грамматик, никакого backtracking: я и слов-то таких не знал тогда — имел то, до чего додумался сам. Зато было весело!

Игру саму я тогда не доделал, конечно. Допилил движок, и игра стала "реализуема". Дальше уже наступал черёд игрового дизайнера и сценариста, затем — художника. А вот эти роли мне были не так интересны, поэтому игра осталась в виде "proof of concept" с четырьмя игровыми экранами. Но своё удовольствие я получил. И догадался сохранить исходники, что позволило в итоге написать эту серию %^D

​​Рубрика "ссылка на видео"!

Let's Reverse: Adventures of Lomax graphics — интересный и довольно необычный скринкаст (куда уж без стримов сейчас?) разбора одной старой игры (The Adventures of Lomax от крутейших Psygnosis) на предмет того, как игра хранит графику.

Зрелище само по себе нескучное, особенно если вы интересуетесь #reverse_engineering, но в этот раз ещё и инструментарий использован примечательный: вся работа делается в IPython REPL. И не в Jupyter, а именно в текстовом режиме — текстом выводятся гистограммы, палитры, даже сама графика! Используется для всего этого фреймворк Mr.Crowbar, предоставляющий eDSL (автор вдохновлялся Django ORM, %)), с помощью которого вы жонглировать байтиками, описывать структуры и обрабатывать их так, как Web-разработчики работают с моделями ORM. Собственно это видео как раз и записано автором фреймворка как demo для "Мистера Фомки".

Сам я положу Mr.Crowbar в копилочку, а вам желаю приятного просмотра! А может быть даже и вдохновлю кого-то (менее ленивого, чем я) что-то эдакое пореверсить >;^F

#python #gamedev #video

Выступил на днях на online встрече FProg SPb. Рассказал про #gamedev на #racket — ага, как обычно, про что-то странное :)

Целью ставил перед собой демонстрацию искоробочных возможностей Racket в роли платформы для образовательного игростроя: показал, как можно использовать "How to Design Programs" Teachpacks в начале для рисования картинок, а позже уже и для создания клиент-серверной игры!

На всех уровнях (картинка, анимация, игровой мир, игровая вселенная) эти teachpacks предоставляют хорошо продуманные абстракции. Которые ученики могут в последствии использовать в качестве источника вдохновения при построении других программ. Собственно, потому курс и называется "How to Design Programs" ;)

Курс, кстати, очень хорош. Крайне рекомендую к ознакомлению — даже если вы уже знаете, как дизайнить эти ваши программы! Хорошо смотрится и продолжение "How to Design Classes", но про него я только наслышан и "подглядывал", зато знаю, что этот курс использует семейство диалектов Java, реализованное в Racket. Языки под тему — это в целом общий для обоих курсов приём: на каждом этапе обучения используется специально ограниченный язык, чтобы ученики не забегали вперёд и оставались в рамках темы. Каждый последующий язык-под-тему расширяет предыдущий, поэтому получается и видеть разницу, и одновременно наследовать опыт (объектненько!).

Я вообще считаю, что использование расширяющих друг друга языков работает лучше, чем изучение того же ООП на примере разных языков, заставляющее с каждым языком провести несколько незабываемых часов только для того, чтобы отвыкнуть-привыкнуть.

Этот же подход к языкам-темам присутствует в книжке "Beautiful Racket", которая вообще проповедует Language-Oriented Programming. Когда устаёшь от формошлёпства через ямлодокеры, такие "параллельные миры" могут стать отлично отдушиной. Так что я и книжку рекомендую, да.

Ну вот. Хотел просто запостить ссылку на видео про геймдев, а в итоге скатился в образование и саморазвитие. Ну и ладно, блог мой, поэтому могу!

#education #racket #gamedev

​​Есть такой протокол — Gopher). Отвечает за передачу текста поверх TCP/IP и организацию навигации через некое подобие меню. Был изобретён ещё до этого вашего HTTP, подходил для текстовых терминалов, но потом был благополучно забыт, уступив место привычному Вебу.

Тем не менее, некоторые ценители старины (ретрограды, чего уж там!) протокола продолжают поддерживать в рабочем состоянии Gopher-ресурсы, хотя уже и Web-браузеры оный давно не отображают и приходится "сёрфить" с помощью отдельного софта. В основном людей привлекает простота и "честность" — протокол просто-напросто ничего не умеет, кроме как передавать текст :)

Но даже основные функции старичок Gopher реализует по-старинке : ни вам rich content, ни какой либо безопасности. И Unicode тоже нет. Вон, даже FTP дорос до SFTP, а не смог. И всё сложнее себя заставить использовать протокол не только лишь ради самого процесса использования.

И тут на сцену выходит Gemini — идейный наследник Гофера, "новый простой Web". Посудите сами:

- есть статусы как в HTTP, но их меньше и сами они проще и однозначнее,
- основной контент кодируется текстовым форматом text/gemini, который похож на Markdown (только строго построчный и минималистичный),
- передавать можно не только текст, MIME-types поддерживаются,
- TLS со стороны сервера обязателен, так что секурненько,
- вместо cookies используется клиентский TLS, то есть клиент решает, когда ему менять identity — уже просто так не потрекаешь!

Протоколу Gemini недавно исполнился год, но активности в сообществе уже довольно много: люди ведут дневники (gemlogs), держат Gemini-зеркало Википедии, пишут серверы и клиенты на разных языках. Есть у "нового Веба" и поисковики, и каталоги ссылок (помните, что это такое?). Посерфить можно через прокси с помощью обычного браузера или сразу установить один из Gemini-браузеров, словом, есть и контент и средства для его потребления. Да, движение молодо, но энергией оно пока полнится!

Я и сам как-то подустал от современного Web со всей его сложностью, так что изучаю всё это "околоблизнецовое" с неподдельным интересом. Хочу поднять свой ресурсик и зеркалировать туда да хоть вот этот самый канальчик. В качестве языка возьму Rust или Haskell, а серверную реализацию напишу, неверное, сам — так интереснее! Так что, как г-рится, stay tuned!

А вам предлагаю почитать спецификацию протокола, а затем прогуляться по Gemini Gateway дабы познакомиться с сообществом и экосистемой.

​​А помните, как вы подключались к UNIX-машине под своим пользователем и делили ресурсы машины с десятком-другим таких же жильцов этой цифровой коммуналки? Я не помню: не застал :) Но наслышан и имел пунктик приобщиться к чему-то такому однажды. Так вот, я нашёл возможность!

В 1990е на больших машинах с кучей пользователей их (пользователей) Web-страницы на общем хосте имели адреса вида host.dom/~username и тильда явно выделяла имя пользователя. Это были так называемые "tilda sites". И вот в 2014 некий Paul Ford интересу ради решил воссоздать явление в миниатюре и создал <https://tilde.club>. Вы могли попросить завести вам учётную запись и получали в итоге доступ на сервер по SSH. А далее вы брали в руки $EDITOR и писали себе страничку на старом добром HTML — романтика! Сервер заработал, и, как говорится, завертелось! Больше про историю "появления явления" можно почитать тут, а я закончу сий экскурс в историю.

Сейчас Tilde-серверов существует достаточное количество. Практически каждый из них, это обычный компьютер, который не выключают на ночь. Поэтому от сотен пользователей машины ожидается соблюдение определённых норм и правил — проще говоря, монополизирование ресурсов машины не приветствуется. Ресурсы — общие и используются сообща, цифровой коммунизм :) На что же хватает ресурсов одной не самой мощной машины? На типичном tilde-сервере есть Web-сервер страниц пользователей (кто бы сомневался?), Wiki, IRC-подобный чат между пользователями (снаружи машины не доступен), столь же локальный BBS-подобный форум, нередко — какие-то многопользовательские игры с текстовым интерфейсом (ага, MUD). Кто-то дополнительно разворачивает сервисы вроде Gitea, поднимает сервер Minecraft, ноду Mastodon).

Если вы вдруг решите приобщиться и завести себе учётку на какой-нибудь тильде под управлением OpenBSD, то вам стоит пройти сюда: <https://tildeverse.org/> Это хаб сообщества, на котором вы сможете найти себе сервер по вкусу. Или, скажем, почитать тематический zine.

Я лично себе заимел учётку на <https://tilde.town>. Это Linux-машина, так что всё привычно. Общая атмосфера — нарочито дружественная, все занимаются забавными пустяками, вроде рисования своих вагонов к ASCII-паровозу (для этого нужно правильно названный текстовый файлик иметь в $HOME) или коллективного написания IF-истории про космос и голопалубы.

Моя страничка пока выглядит так, HTML для неё я сгенерировать скриптом на #racket. Генерировал на своей машине, но при желании смогу сделать это и с сервера: Racket на машине имеется, также как и GHC, не говоря уж про прочие пайтоны. Местный зоопарк языков вполне неплох, так что можно покодить что-то не сильно нагружающее машину, не выходя из терминала (Vim и Emacs тоже имеются). Имейте в виду, если вдруг захотите сгенерировать "хомяка" программой на BASIC :)