Historically, you need at least 2 layouts at a computer - English and Russian.

On top of that, I’ve been using Colemak-type layouts (Vanilla / DH / CAWS) for a while, plus custom Russian modifications like RulemakDH or RulemakCAWS (see Rulemak-CAWS.md)

And all of this across two different matrices - regular Staggered ANSI and a split Columnar one.

Still haven’t reached any kind of ideal. It’s just clear that ANSI and Split keyboards need different layouts.

It would be great to ditch ANSI keyboards completely. But a couple times a week I have to use a laptop, and lugging the split around every time isn’t always convenient.

So I constantly have to tweak layout configs. Change them. Adjust for different keyboards. Different tasks.

XKB: what it is and why it’s pain

XKB (X Keyboard Extension) is the standard keyboard layout system on Linux. It’s under the hood of both X11 and Wayland. The entire keyboard - from keypress to character on screen - goes through XKB.

You can define multiple layers (Base, Shift, AltGr, AltGr+Shift). Assign any symbols to any keys. Dead keys, compose sequences, modifier remapping. Whatever you want.

XKB configuration means text files. It looks roughly like this:

key <AD01> {
    type[group1]= "ALPHABETIC",
    symbols[Group1]= [ q, Q, backslash, division ]
};
key <AD02> {
    type[group1]= "ALPHABETIC",
    symbols[Group1]= [ w, W, U0312, division ]
};

One block per key. One symbol per layer. Times 50+ keys.

And you sit there with a keysym table, manually transcribing symbols, constantly double-checking so you don’t mess up. Inconvenient, easy to make mistakes, etc etc.

So yeah, that’s exactly what drove me to build xkb.sccl.cc.

xkb.sccl.cc

A visual XKB layout editor for Linux. In the browser.

Nothing special - just a QoL thing. Click the buttons you need, copy the config, off you go.

Built with Zine - the same Zig SSG that powers the main sccl.cc. Pure HTML+CSS+JS, no frameworks, everything client-side.

All standard XKB symbols for binding are already on the site. But XKB can take any Unicode character, so you’re not limited to just those.

The idea is simple: you click a key on the on-screen keyboard, a keysym search pops up, you pick the symbol. Repeat for each layer. Done - hit “copy xkb config” or download the .xkb file.

How to use

Generated a config - two ways to apply:

Quick (temporary):

xkbcomp my-layout.xkb $DISPLAY

Applies immediately. Until reboot or relogin.

Persistent:
Drop the .xkb file in /etc/X11/xkb/symbols/, edit evdev.xml so the system knows about your layout. Or use your DE’s keyboard settings.

On NixOS with sccl_nix the layout is already parametrized - you can drop the generated config alongside and hook it up via sccl.keyboard.

Contributing

The site stores configs in localdata in its own format. You can download it as JSON at any time.

If you’ve cooked up a decent layout - create a PR: drop the JSON into assets/presets/ and the layout shows up in the presets list on the site.
you can PR on github too, but it’s not quite as convenient for me.

maybe I’ll add direct import from existing xkb configs later. would be nice.

Everything is, of course, open source.

Так исторически сложилось, что за компьютером нужно минимум 2 лейаута - Английский и Русский.

К тому же уже давно использую раскладки вида Colemak (Vanilla / DH / CAWS) и свои модификации для русского типа RulemakDH иль RulemakCAWS (см Rulemak-CAWS.md)

Да всё это на двух разных матрицах - обычной Staggered ANSI и раздельной Columnar.

Пока до какого-то идеала дойти не удалось. Ясно лишь что для ANSI и Split клавиатуры нужны разные раскладки.

Было бы круто конечно полностью отказаться от ANSI клавиатур. Но пару раз в неделю приходится пользоваться ноутбуком, и каждый раз таскать с собой сплит не всегда удобно.

Соответсвенно конфиги раскладок мне надо постоянно редачить. Менять. Подгонять под разные клавы. Под разные задачи.

XKB: что это и почему боль

XKB (X Keyboard Extension) - это стандартная система клавиатурных раскладок в Linux. Она под капотом у X11 и Wayland. Вся клавиатура - от нажатия клавиши до символа на экране - проходит через XKB.

Можно определить несколько слоёв (Base, Shift, AltGr, AltGr+Shift). Можно назначать любые символы на любые клавиши. Можно dead keys, compose sequences, переопределение модификаторов. Всё что угодно.

Конфигурация XKB - это текстовые файлы. Выглядит это примерно так:

key <AD01> {
    type[group1]= "ALPHABETIC",
    symbols[Group1]= [ q, Q, backslash, division ]
};
key <AD02> {
    type[group1]= "ALPHABETIC",
    symbols[Group1]= [ w, W, U0312, division ]
};

На каждую кнопку - свой блок. На каждый слой - свой символ. И так 50+ кнопок.

И ты сидишь с таблицей keysym-ов, ручками переписываешь символы, постоянно сверяясь чтоб не ошибиться. Неудобно, легко ошибиться и т.д и т.п..

Собсна, именно это задолбало настолько, что появился xkb.sccl.cc.

xkb.sccl.cc

Визуальный редактор раскладок XKB для Linux. В вебе.

Ничего особенного - просто QoL штучка. Натыкал нужные кнопки, скопировал конфиг, пользуешься.

На чём сделано: Zine - тот же SSG на Zig, на котором работает основной sccl.cc. Чистый HTML+CSS+JS, никаких фреймворков, всё на клиенте.

Все стандартные символы из XKB для бинда уже есть на сайте. Но XKB умеет вбивать любые Unicode символы, т.ч. только ими можно не ограничиваться.

Принцип простой: тыкаешь на кнопку на экранной клавиатуре, появляется поиск по keysym-ам, выбираешь нужный символ. Повторяешь для каждого слоя. Готово - жмёшь “copy xkb config” или скачиваешь .xkb файл.

Как юзать

Сгенерил конфиг - дальше два пути:

Быстрый (временно):

xkbcomp my-layout.xkb $DISPLAY

Применится сразу. До перезагрузки или перелогина.

Персистентный:
Кладёшь .xkb файл в /etc/X11/xkb/symbols/, правишь evdev.xml чтоб система знала про твою раскладку. Или через DE-настройки клавиатуры.

На NixOS со sccl_nix раскладка уже параметризована - сгенеренный конфиг можно положить рядом и подключить через sccl.keyboard.

Contributing

Сайт хранит конфиг в localdata в своём формате. В любой момент его можно скачать как JSON.

Если запилил годную раскладку - создавай PR: скидываешь JSON в assets/presets/ и раскладка появляется на сайте в списке пресетов.
pr можно и на github, но мне не совсем удобно.

потом может добавлю прямой импорт из существующего xkb конфига. было б удобно.

Всё естестна опенсурс.

My site sccl.cc has a whole history of optimizations.

First there was the migration from Astro to Zine - separate shitpost about that. Then squeezing everything into 1 RTT - already wrote a deep article on that.

tl;dr: the site is compressed to 13kb gzip, loads in a single TCP packet, one round trip for data.

So the site flies. But I wanted to add 88x31 badges.

You know, those tiny buttons everyone puts in their site footer. Like “Powered by something”, links to friends, clubs like 512kb.club and 14kb.club.

It’s web classics. How do you even live without them.

But there’s a catch: the site is optimized down to one request. And now you have a dozen badges, each 200++ bytes but each a separate HTTP request.

Gotta figure something out.

88x31: where it even came from

The 88 by 31 pixel format is one of the oldest web traditions.

It all started with Netscape. In 1996 they launched the “Netscape Now!” program - buttons you could put on your site to show you’re using their browser.

88x31, gray background, beveled edges, “Netscape Now!” text.

Then others picked it up. Microsoft with Internet Explorer. GeoCities for their users. Then “Best viewed in…”, “Powered by…” - off it went.

The browser wars era made these buttons ubiquitous. It was a way to show affiliation: I use this browser, I’m hosted on this platform, I’m in this webring.

Now the format is having a second birth. Neocities, indie web revival, all sorts of clubs (512kb.club, 14kb.club, no-js.club) - each has its own badge. And people are plastering them all over their sites.

neonaut.neocities.org has compiled an archive of 13,051 badges from 11,011 Neocitizens. 82 megabytes of pure 88x31. They even have a counter for dead sites ;k

btw, this is the same neonaut who wrote the essay on the history of 88x31 - that’s where the facts above come from. recommended.

The problem: 67 requests

Usually badges are inserted as <img src="..."> and no one gives a shit.

It looks something like this:

Each badge is a separate HTTP request. Font, styles, script, 67 images.

And each request is a full cycle: DNS lookup (if cold), TCP handshake, TLS handshake. Even if the image weighs a measly 200 bytes - the overhead is dozens of times larger than the image itself.

At least most people don’t hotlink and host the badges themselves.
otherwise it would be a complete fucking disaster

But even with local hosting, 67 requests is a shitton. If you have HTTP/2 and keep-alive, some of the cost gets amortized. But the initial setup still exists. And each request is a delay.

And my site is tightly optimized for 1 RTT. I can’t just casually add 67 requests.
the philosophy doesn’t allow it.

Plus, besides speed, there’s a bonus of bypassing Russian TSPU - the first packet doesn’t get caught if it fits in initcwnd.

What do we do

Obviously cramming all images into the same 1 RTT won’t work - too fat.

Inlining in HTML isn’t an option either - each badge in base64 adds ~33% to the weight, and we’d(I’d) fly past initcwnd.

But you can do it differently: collect all badges into a single CSS file as base64 and load it with ONE request.

Second request, yeah. But you can have 100 badges - still one request.

The idea: at site build time, a generator reads a config, fetches current badges (or takes local ones), converts to base64, stuffs into CSS as background-image.

How it works

The CSS is generated at site build time. Input is a config:

{
    "badges": [
      {
        "url": "https://example.com/assets/example.png",
        "href": "https://example.com",
        "alt": "example.com",
        "file": "1.png"
      },
      {
        "href": "https://test.com",
        "alt": "test.com",
        "local": "../img/test.com",
        "file": "2.png"
      }
    ]
}

Two modes:

• url - fetches the badge from the specified site
• local - takes a local file (if the badge is already downloaded and in the repo)

The generator walks the config, downloads/reads files, converts to base64, generates CSS:

.badge{display:inline-block;width:88px;height:31px;image-rendering:pixelated;image-rendering:crisp-edges}
.badge-0{background:url(data:image/gif;base64,R0lGODdhWAAfAHcAACH...) no-repeat 0 0}
.badge-1{background:url(data:image/png;base64,iVBORw0KGgoAAAA...) no-repeat 0 0}
/* and so on */

Then in the HTML, instead of 67 <img> tags, we insert 67 <a class="badge badge-N"> links with a CSS background image.

Applied as a style:

The profit

Instead of 67 separate requests per badge, we get:

Main site: 1 HTTP request, 13kb gzip, 1 RTT. That’s how it was - already wrote about this.

Badges: 1 HTTP request, one CSS file with all images in base64.

the “data:” lines are not http requests - the browser decodes base64 into images locally.

Total: TWO requests for the entire site with all badges. Instead of 68+.

If badges grow way past 10 - the CSS file might not fit in one initcwnd and go to 2 RTT. But the difference between 1 and 2 RTT isn’t dramatic when it’s not the main content. Badges in the footer - the user won’t see them right away anyway. plus I have a fallback with buttons without images

The downside: base64 adds ~33% to binary data size. For 88x31 badges (usually < 1kb) this is pocket change. But if you have a hundred badges at 5kb each - it’ll start to show.

Also the images don’t cache separately. On page refresh - badges reload together with the CSS. But CSS gets cached by the browser too, so in practice you don’t feel the difference.

In my case the benefit is clear: the site stays fast, badges are there, everything looks as it should.

У меня на сайте sccl.cc есть целая история оптимизаций.

Сначала был переезд с Astro на Zine - об этом отдельный шитпост. Потом впихивание всего в 1 RTT - тут уже навалена глубокая статья.

если кратко: сайт ужат до 13kb gzip, грузится одним TCP-пакетом, один round trip на данные.

Вроде сайт летает. Но хочется добавить 88x31 баннеры.

Ну эти маленькие кнопочки, которые все пихают в футер сайта. Типа “Powered by something”, ссылки на друзей, клубы типа 512kb.club и 14kb.club.

Это ж классика веба. Как без них.

Но есть нюанс: сайт оптимизирован до одного запроса. А тут у тебя дцать баннеров, каждый по 200++ байт но каждый - отдельный HTTP-запрос.

Нужно чота придумывать.

88x31: откуда вообще

Формат 88 на 31 пиксель - это одна из старейших традиций веба.

Началось всё с Netscape. В 1996 году они запустили программу “Netscape Now!” - кнопки которые можно было вставить на сайт чтоб показать что ты юзаешь их браузер.

Потом идею подхватили. Microsoft со своим Internet Explorer. GeoCities для своих пользователей. Потом “Best viewed in…”, “Powered by…” - понеслась.

Эпоха browser wars сделала эти кнопки вездесущими. Это был способ показать принадлежность: я юзаю этот браузер, я хостюсь на этой платформе, я состою в этом веб-ринге.

Сейчас формат переживает второе рождение. Neocities, indie web revival, всякие клубы (512kb.club, 14kb.club, no-js.club) - у каждого свой баннер. И народ массово клеит их на сайты.

neonaut.neocities.org собрал архив из 13 051 баннера с 11 011 неоситизенов. 82 мегабайта чистого 88x31. Есть даже счётчик умерших сайтов ;k

к слову, это тот же neonaut который написал эссе про историю 88x31 - оттуда и факты выше. рекомендую.

Проблема: 67 запросов

Обычно баннеры вставляют <img src="..."> и похуй.

Выглядит это примерно так:

Каждый баннер - отдельный HTTP-запрос. Шрифт, стили, скрипт, 67 картинок.

И каждый запрос это полный цикл: DNS lookup (если холодный), TCP handshake, TLS handshake. Даже если картинка весит жалкие 200 байт - накладные расходы в десятки раз больше самой картинки.

Благо большинство не хотлинкит, а хостит баннеры у себя.
а то ваще пиздец бы был

Но даже с локальным хостингом 67 запросов - это дохуя. Если у тебя HTTP/2 и keep-alive, часть расходов амортизируется. Но первый setup всё равно есть. И каждый запрос это задержка.

А у меня сайт жёстко оптимизирован под 1 RTT. Я не могу просто взять и добавить 67 запросов.
философия не позволяет.

Тем более помимо скорости тут ещё и бонус в виде обхода расиянских ТСПУ - первый пакет не ловится, если влезает в initcwnd.

Чо делаем

Ясен хуй впихнуть все картинки в тот же 1 RTT не получится - слишком жирно.

Инлайнить в HTML тоже не вариант - каждый баннер в base64 добавит ~33% к весу, и мы(я) вылетим за initcwnd.

Но можно сделать по-другому: собрать все баннеры в один CSS-файл base64 и подгрузить его ОДНИМ запросом.

Второй запрос, да. Но зато баннеров может быть хоть 100 - это всё равно один запрос.

Идея: при билде сайта генератор читает конфиг, фетчит актуальные баннеры (или берёт локальные), конвертит в base64, пихает в CSS как background-image.

Как работает

CSS генерится при билде сайта. На входе конфиг:

{
    "badges": [
      {
        "url": "https://example.com/assets/example.png",
        "href": "https://example.com",
        "alt": "example.com",
        "file": "1.png"
      },
      {
        "href": "https://test.com",
        "alt": "test.com",
        "local": "../img/test.com",
        "file": "2.png"
      }
    ]
}

Два режима:

• url - фетчит баннер с указанного сайта
• local - берёт локальный файл (если баннер уже скачан и лежит в репе)

Генератор обходит конфиг, скачивает/читает файлы, конвертит в base64, генерит CSS:

.badge{display:inline-block;width:88px;height:31px;image-rendering:pixelated;image-rendering:crisp-edges}
.badge-0{background:url(data:image/gif;base64,R0lGODdhWAAfAHcAACH...) no-repeat 0 0}
.badge-1{background:url(data:image/png;base64,iVBORw0KGgoAAAA...) no-repeat 0 0}
/* и так далее */

Дальше в HTML вместо 67 <img> тегов вставляем 67 <a class="badge badge-N"> ссылок с фоновой картинкой из CSS.

Применяется как стиль:

Профит

Вместо 67 отдельных запросов на каждый баннер получаем:

Основной сайт: 1 HTTP-запрос, 12kb gzip, 1 RTT. Ну это как и было - про это я уже писал.

Баннеры: 1 HTTP-запрос, один CSS-файл со всеми картинками в base64.

строки “data:” не являются http-запросами - это браузер декодит base64 в картинку локально.

Итого: ДВА запроса на весь сайт со всеми баннерами. Вместо 68+.

Если баннеров станет сильно больше 10 - CSS-файл может не влезть в один initcwnd и уйти на 2 RTT. Но разница между 1 и 2 RTT не драматична, когда это не основной контент. Баннеры в футере - пользователь их всё равно не видит сразу. к тому же у меня есть fallback с кнопочками без картинки

Из минусов: base64 добавляет ~33% к размеру бинарных данных. Для 88x31 баннеров (обычно < 1kb) это копейки. Но если у тебя сотня баннеров по 5kb каждый - уже начнёт быть заметно.

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

В моём случае профит очевиден: сайт остаётся быстрым, баннеры есть, всё выглядит как надо.

Here, real requests for reference.

A site that fits in 14kb:

One that doesn’t:

Download - that’s the actual site content.
1 ms vs 63 ms - 63x speed difference, with only a 7x weight difference.

How the hell?

This braindump is an attempt to dig into this topic down to the guts. TCP, DNS, TLS, slow start, the 1986 congestion collapse. And along the way, the philosophy of small web: why a tiny site is respect for the user, not a numbers circlejerk.

and I’ll talk about my own sccl.cc optimization

Whatamhow TCP

Before the server sends even a single byte of HTML, a fuckton of things happen.

Three-way handshake

Every TCP connection starts with a three-way handshake:

1. Client sends SYN
2. Server replies SYN-ACK
3. Client finishes with ACK

Three messages back and forth. Only then can you send data.
That’s +1 RTT just to say hello.

There’s TCP Fast Open (TFO) - lets you cram data into the SYN packet. But it only works for repeat connections and needs support on both sides. Rare in practice.

Congestion collapse 1986

In early 1986, the internet nearly died.

Node count passed 5,000, bandwidth was uneven. TCP without congestion control just flooded the channel with packets. Routers dropped them, hosts resent, routers dropped more - avalanche.

Throughput dropped 1,000x. The network became unusable.

They called it congestion collapse.

In 1988, Van Jacobson published “Congestion Avoidance and Control” describing four algorithms that saved the internet: slow-start, congestion avoidance, fast retransmit, fast recovery.

These four became mandatory parts of TCP. They essentially prevented the internet from collapsing in the 80s and 90s as traffic grew exponentially.

Slow start

The idea is simple: the server has no idea what the channel bandwidth to the client is.

If you blast 100 packets immediately - you can clog the network and trigger that same congestion collapse. So you start small and ramp up.

The server maintains a variable called cwnd (congestion window) - how many packets it can send without waiting for ACK.

initcwnd - the starting value of this window:

• Originally: 1 segment
• RFC 3390: 4 segments
• RFC 6928 (2013): 10 segments

Google pushed the increase to 10 in 2013 through experiments showing it doesn’t make things worse. Some CDNs (Cloudflare, Fastly) set it to 30 or more.

Then exponential growth:

Server sent 10 packets - waits for ACK
ACK arrives - window doubles to 20
Sent 20 - waits
Window to 40, then 80…

Each cycle is one RTT.
The bigger the response, the more rounds.
If the response fits in initcwnd - it flies out as a single packet with no waiting - one round trip.

For large files (images, video) this isn’t a problem - TCP has time to ramp up over a few RTTs. But most website files are under 100kb - and that’s where the pain starts.

Look: a 100mb file - first couple RTTs it ramps up, then pumps at full speed. Those first RTTs are a drop in the ocean.

A 30kb file - lands right where slow start is just beginning to ramp. Instead of one RTT - two. Instead of ~50ms - ~100ms.

And if there’s a dozen such files, each on a new connection - each goes through this dance from scratch.

Who burns what

Before the server even gets to sending HTML - a whole ritual. Every step is an RTT.

DNS: +1 RTT
Domain resolution. Usually cached, so in most cases 0ms. But a cold lookup - honest RTT.

TCP handshake: +1 RTT
SYN, SYN-ACK, ACK. No way around it.

TLS: +2 RTT (or +1 with TLS 1.3)
TLS 1.2: 2 RTT. TLS 1.3: 1 RTT. With 0-RTT resumption you can get it down to 0, but only for repeat connections.

Btw, the certificate itself can weigh several kilobytes and not fit in initcwnd. Simon Hørup Eskildsen analyzed the Danish newspaper information.dk - certificate was 6908 bytes, initcwnd was 3 (old Linux). The certificate didn’t fit in the window, and the TLS handshake took 3 RTT instead of 2. Just because the server waited for ACK mid-certificate.

Fuck.

Total: minimum 3-4 RTT before the first byte of HTML. And we haven’t even started sending content. Once we do - slow start kicks in.

Satellite

There’s a great example from Nathaniel at endtimes.dev:

Oil rig. Dudes forgot their D&D dice and want to hit missingdice.com over satellite internet.

Packet path:

phone -> WiFi router -> dish -> satellite (35,786 km) -> ground station -> server

One RTT: 1ms (router) + 120ms (ground-to-satellite) + 120ms (satellite-to-ground) + 60ms (ground-to-server) - roughly 300ms one way.

Full round trip: 612ms. That’s one RTT.

With 4 RTTs (DNS + TCP + 2xTLS) before the first byte: 2.5 seconds.
With slow start over several rounds - all of 4-5 seconds.

For a dice website.

You see it now, right?

The magic of 14,600

Let’s count:

• MTU Ethernet: 1500 bytes
• IP header: 20 bytes
• TCP header: 20 bytes
• Payload: 1500 - 40 = 1460 bytes per packet
• initcwnd = 10 packets
• 10 x 1460 = 14,600 bytes = ~14.25 KB

That’s where the number comes from.

Step function

It’s not linear.

14kb - 1 RTT.
15kb - 2 RTT.
29kb - 2 RTT.
30kb - 3 RTT.

Every time you cross a window boundary - a whole RTT gets added. The difference between 14kb and 15kb can be bigger than between 15kb and 40kb.

The fun part: HTML gets compressed with gzip. 27kb raw easily becomes 12kb gzip. And 12kb - still in initcwnd, one RTT.

14KB Club counts uncompressed. So by club rules you need to fit in 14kb raw HTML.

But in reality, a 20-30kb raw site with gzip is almost as fast as a “pure” 14kb site. The difference - nanoseconds on decompression.

Though counting compressed would make more sense, imo. Whatever.

What about HTTP/2, HTTP/3?

There’s this idea that multiplexing kills the 14kb rule. It doesn’t.

HTTP/2 lets you send multiple requests over one TCP connection. But TCP slow start is still there - it’s a TCP thing, not HTTP. The first request still goes through slow start.

HTTP/3 (QUIC) runs over UDP. But the QUIC spec recommends the same initcwnd of 10 packets.

Plus, the HTTPS handshake and HTTP/2 preface eat part of the initial window. Barry Pollard analyzed in detail that by the time HTML is sent, the window may already be larger than 10 - ACKs were being sent during TLS negotiation. So “exactly 14kb” is a simplification.

But the mechanics are the same. Understanding them beats obsessing over the number.

Small web is not about kilobytes

The small site thing - it’s not just about speed. It’s about philosophy.

Clubs

There’s a whole ecosystem: 1MB Club, 512KB Club, 250KB Club, 14KB Club. Plus various no-js.club, nocss.club and such.

The 512KB Club homepage says it outright:

The internet has become a bloated mess. Huge JavaScript libraries, countless client-side queries and overly complex frontend frameworks are par for the course these days.

And they’re right.

NYT - a newspaper layout, text and images - weighs 9 megabytes over 891 requests, half of which is JavaScript. That’s fucked up.

A site that by nature can’t be heavy, somehow turned into a monster. And ok, if it were a webgl experiment. It’s a newspaper. Text and pictures.

Motherfucking website

If you haven’t seen motherfuckingwebsite.com - go look. One HTML file, no CSS, no JS. Black text on white background. 5kb.

Then came bestmotherfucking.website - minimal CSS, 78 bytes inline. Then thebestmotherfucking.website - with a dark theme, but 132kb, kinda too much.

There’s also justfuckingusehtml.com - 29kb of pure HTML. No frameworks, no bundlers, no transpilers. Just HTML.

This whole lineup - not just a meme. It’s a manifesto.

Respect

Remember the satellite example? 612ms per RTT. Someone on an oil rig wants to visit a site - and it takes 5 seconds to load.

Not because the content is heavy.
Because the developer didn’t give a shit.

Threw in 5 megabytes of JS, three 200kb fonts, PNG images instead of WebP, tracking, ads.

A small site is respect for the user. For their time. For their data plan. For their battery. For the fact that not everyone has fiber and 5G.

Ilya Grigorik in HPBN writes:

No bit is faster than one that is not sent.

It’s not about “make your site gray and dull”. It’s about “don’t drag a fuckload of kilobytes the user doesn’t need”.

By the way, the 512KB Club gives a Green Team badge to sites under 100kb. sccl.cc at 27kb raw would qualify. But I wanted more.

Optimizing sccl.cc

I have this little site sccl.cc. Built on Zine - an SSG in Zig. Three pages: contacts, projects, peripherals.

before migrating to Zine it was on Astro and weighed 150+kb, see Migration-from-Astro-to-Zine.md

What the server was originally sending:

• HTML (~15kb)
• Space Mono + Martian Mono woff2 (~40kb)
• Avatar PNG (~2mb)
• Favicon PNG (~1mb)

screenshot is already a bit optimized, it was worse :skull:

Four requests per page for content that weighs practically nothing. And this is with keep-alive and HTTP/2 - setup once, but every new connection, every new tab - all over again.

Plan: everything in one HTML. Base64 inline all the things. Zero external requests. Fit in initcwnd with compression.

Font

The fattest thing. 2 fonts + bold variants = 40kb.

Honestly, custom fonts are fucking unnecessary most of the time. But aesthetics won - decided to keep one, stripping the file down to ASCII only.

Tool: pyftsubset from fonttools. Strips out non-latin ranges, characters not used on the site.

Result: 4.2kb, in base64 - 5.7kb of text in the HTML.

Avatar

Pixel art, rendered at 400%, PNG with alpha channel. Fat.

Shakalizer, three colors, PNG - 1.9kb. Convert to WebP - 702 bytes.

Base64: 940 bytes.

Favicon

Same tricks. 199 bytes in PNG (for tiny images it beats WebP).

Base64: 268 bytes.

JS

Animated buttons, animated background, an easter egg with animation. All for looks. Actually useful stuff - almost none.

But I wanted to keep the functionality. Everything went inline. ~4kb of scripts the site would work fine without. But pretty.

Result

Before: 4 requests, ~50kb

After: 1 request, 12kb gzip / 27kb raw

Fits in initcwnd. One TCP data packet after the handshakes - and the site is ready.

The inline dilemma

Inlining everything is a tradeoff. There’s a cost.

Caching

A font in base64 inside HTML - doesn’t get cached. When navigating to another page, the browser downloads it again, because it’s part of the HTML.

With a separate file, the font would be cached after the first load. The second page would load without it.

When to choose what

Everything in one HTML (base64 fonts)
2 pages at 14kb each
Each - 1 RTT
But every time you eat the full 14kb, even if the font repeats

HTML + separate font
2 pages at 8kb + 4kb font separate
First visit: 2 requests
Navigation: only 8kb, font cached

In the real internet, you won’t feel the difference between 14kb and 8kb - both fit in one initcwnd.

But delays between requests - you will.

Overhead

Inline weighs a bit more than an external dependency - base64 adds ~33% to binary data. If you’re already not exceeding initcwnd with external resources - you don’t fucking need inline.

It makes sense when the difference between “fit in one RTT” and “didn’t fit” is critical.

For sccl.cc the difference was dramatic: 4 requests vs 1, 50kb vs 12kb. Worth it.

Bottom line

14kb is not a magic number. It’s a consequence of TCP architecture, designed for reliability and fairness, not for first-load speed.

Understanding the transport layer gives you more than blindly following “the 14kb rule”. Sometimes you need inline, sometimes separate files with caching. Sometimes 30kb raw with gzip is almost the same as 14kb without.

But the philosophy remains: less is faster. And the less crap you drag onto your site, the more respect for the user.

Вот в пример реальные запросы.

Вот сайт который влезает в 14кб:

А вот который не влезает:

Download - это и есть контент сайта.
1 ms против 63 ms - разница скорости в 63 раза, при разнице веса всего 7 раз.

С хуя ли?

Ета писанина по верхам о потрохах TCP, DNS, TLS, slow start, congestion collapse 1986 года. И заодно филососия small web: почему маленький сайт - это уважение к пользователю, а не дрочка на циферки.

ну и немного про решения на sccl.cc в конце.

Чотамкак TCP

Прежде чем сервер отдаст хоть байт HTML, происходит овердохуя всего.

Три рукопожатия

Любое TCP-соединение начинает с three-way handshake:

1. Клиент шлёт SYN
2. Сервер отвечает SYN-ACK
3. Клиент добивает ACK

Три сообщения туда-сюда. И только потом можно слать данные.
Это +1 RTT просто на то чтоб поздороваться.

Есть TCP Fast Open (TFO) - позволяет впихнуть данные в SYN-пакет. Но работает только для повторных соединений и требует поддержки с обеих сторон. В реальности редкость.

Congestion collapse 1986

В начале 1986 интернет почти умер.

Количество узлов перевалило за 5000, bandwidth был неравномерным. TCP без контроля перегрузки просто забивал канал пакетами. Маршрутизаторы дропали, хосты перепосылали, дропали ещё больше - лавина.

Пропускная способность падала в 1000 раз. Сеть становилась нефункциональной.

Это назвали congestion collapse.

В 1988 Ван Якобсон (Van Jacobson) опубликовал статью “Congestion Avoidance and Control” где описал четыре алгоритма, которые спасли интернет: slow-start, congestion avoidance, fast retransmit, fast recovery.

Именно эти четыре штуки стали обязательной частью TCP. И по сути предотвратили коллапс интернета в 80-х и 90-х, пока трафик рос экспоненциально.

Slow start

Идея простая: сервер не знает, какая пропускная способность у канала до клиента.

Если сразу вжарить 100 пакетов - можно забить сеть и получить тот самый congestion collapse. Поэтому начинаем с малого и разгоняемся.

Сервер держит переменную cwnd (congestion window) - сколько пакетов можно отправить не дожидаясь ACK.

initcwnd - начальное значение окна:

• Изначально: 1 сегмент
• RFC 3390: 4 сегмента
• RFC 6928 (2013): 10 сегментов

Google в 2013 продавил повышение до 10 через эксперименты, показав что хуже не становится. Некоторые CDN (Cloudflare, Fastly) ставят 30 и больше.

Дальше экспоненциальный рост:

Сервер отправил 10 пакетов - ждёт ACK
Пришёл ACK - окно удвоилось до 20
Отправил 20 - ждёт
Окно до 40, потом до 80…

Каждый такой цикл - это один RTT.
Чем больше ответ, тем больше раундов.
А если ответ влезает в initcwnd - улетает одним пакетом без ожидания - получаем один round trip.

На больших файлах (картинки, видео) это не проблема - TCP успевает разогнаться за несколько RTT. Но в большинстве случаев на сайтах файлы меньше 100kb - и вот тут начинается боль.

Например: файл на 100mb - первые пару RTT разгоняется, потом льёт на полной скорости. Эти первые RTT - капля в море.

Файл на 30kb - как раз попадает в зону, где slow start только начал разгоняться. Вместо одного RTT - два. Вместо ~50ms - ~100ms.

А если таких файлов дцать и каждый в новом соединении - каждый проходит этот путь заново.

Кто сколько жрёт

Прежде чем сервер вообще дойдёт до отправки HTML - целый ритуал. Каждый этап - RTT.

DNS: +1 RTT
Резолвинг домена. Обычно кешируется, т.ч. в большинстве случаев 0ms. Но cold lookup - честный RTT.

TCP handshake: +1 RTT
SYN, SYN-ACK, ACK. Без вариантов.

TLS: +2 RTT (или +1 с TLS 1.3)
TLS 1.2: 2 RTT. TLS 1.3: 1 RTT. С 0-RTT resumption можно и ваще 0, но это для повторных соединений.

Кста, сертификат может сам по себе весить несколько килобайт и не влезать в initcwnd. Simon Hørup Eskildsen разбирал датскую газету information.dk - сертификат 6908 байт, initcwnd был 3 (старый линукс). Сертификат не влез в окно, и TLS handshake занял не 2 а 3 RTT. Просто потому что сервер ждал ACK посреди отправки сертификата.

Итого: минимум 3-4 RTT до первого байта HTML. И это мы ещё не начали слать контент. А когда начали - включается slow start.

Спутник

Есть отличный пример от Nathaniel с endtimes.dev:

Нефтяная платформа. Чуваки забыли кости для D&D и хотят зайти на missingdice.com через спутниковый интернет.

Путь пакета:

телефон -> WiFi-роутер -> тарелка -> спутник (35 786 км) -> наземная станция -> сервер

Один RTT: 1ms (роутер) + 120ms (земля-спутник) + 120ms (спутник-земля) + 60ms (наземный-сервер) - примерно 300ms в одну сторону.

Полный круг: 612ms. И это один RTT.

С 4 RTT (DNS + TCP + 2xTLS) до первого байта: 2.5 секунды.
С slow start на несколько раундов - все 4-5 секунд.

На сайт с костями.

ок?

Магия 14 600

Считаем:

• MTU Ethernet: 1500 байт
• Заголовок IP: 20 байт
• Заголовок TCP: 20 байт
• Полезная нагрузка: 1500 - 40 = 1460 байт на пакет
• initcwnd = 10 пакетов
• 10 x 1460 = 14 600 байт = ~14.25 KB

Вот откуда число.

Step function

Это не линейно.

14kb - 1 RTT.
15kb - 2 RTT.
29kb - 2 RTT.
30kb - 3 RTT.

Каждый раз когда перепрыгиваешь границу окна - добавляется целый RTT. Разница между 14kb и 15kb может быть больше, чем между 15kb и 40kb.

Прикол в том, что HTML сжимается gzip-ом. 27kb raw легко превращаются в 12kb gzip. И 12kb - всё ещё в initcwnd, один RTT.

14KB Club считает uncompressed. Т.е. по правилам клуба надо влезть в 14kb сырым HTML.

Но в реальности сайт на 20-30kb raw с gzip почти не уступает “чистому” 14kb сайту. Разница - наносекунды на decompression.

Хотя кабута логичнее было бы считать compressed. Ну да ладно.

А HTTP/2, HTTP/3?

Есть мнение что мультиплексирование убивает правило 14kb. Это не так.

HTTP/2 позволяет слать несколько запросов в одном TCP-соединении. Но TCP slow start никуда не делся - это свойство TCP, а не HTTP. Первый запрос всё равно проходит через slow start.

HTTP/3 (QUIC) работает поверх UDP. Но спецификация QUIC рекомендует тот же initcwnd в 10 пакетов.

Плюс HTTPS-рукопожатие и HTTP/2-префейс съедают часть начального окна. Barry Pollard детально разбирал что к моменту отправки HTML окно уже может быть больше 10 - ACKи слались во время TLS-переговоров. Т.ч. “ровно 14kb” - это упрощение.

Но механика та же. Понимать её полезнее чем дрочить на циферки.

Small web - это не про килобайты

Тема маленьких сайтов - она не только про скорость. Она про философию.

Клубы

Есть целая экосистема: 1MB Club, 512KB Club, 250KB Club, 14KB Club. И ещё всякие no-js.club, nocss.club.

512KB Club на главной пишет прямым текстом:

The internet has become a bloated mess. Huge JavaScript libraries, countless client-side queries and overly complex frontend frameworks are par for the course these days.

И ведь правда.

NYT - газетный лейаут, текст и картинки - весит 9 мегабайт на 891 запросе, половина из которых JavaScript. Это пиздец.

Сайт, который по природе не может быть тяжёлым, зачем-то превращён в монстра. И ладно бы это был webgl-эксперимент. Это газета. Текст и картинки.

Motherfucking website

Если не видели motherfuckingwebsite.com - сходите. Один HTML-файл, без CSS, без JS. Чёрный текст на белом фоне. 5kb.

Потом появился bestmotherfucking.website - минимальный CSS, 78 байт инлайн. Потом thebestmotherfucking.website - уже с тёмной темой, но 132kb, кабута многовато.

Есть ещё justfuckingusehtml.com - 29kb чистого HTML. Никаких фреймворков, сборщиков, транспайлеров. Just HTML.

Вся эта линейка - не просто мем. Это манифест.

Уважение

Выше был пример со спутником - 612ms на RTT. Человек на нефтяной платформе хочет зайти на сайт - и сайт грузится 5 секунд.

Не потому что контент тяжёлый.
Потому что разработчику было похуй.

Кинул 5 мегабайт JS, три шрифта по 200kb, картинки в PNG вместо WebP, трекинг, рекламу.

Маленький сайт - это уважение к пользователю. К его времени. К его трафику. К его батарейке. К тому что не у всех оптоволокно и 5G.

Ilya Grigorik в HPBN пишет:

No bit is faster than one that is not sent.

Это не про “сделать сайт серым и унылым”. Это про “не тащить лютые килобайты того, что пользователю нахуй не нужно”.

К слову, 512KB Club даёт звание Green Team сайтам до 100kb. sccl.cc со своими 27kb raw влез бы. Но хотелось большего.

Оптимизация sccl.cc

У меня есть сайтец sccl.cc. Запилен на Zine - SSG на Zig. Три страницы: contacts, projects, peripherals.

до переезда на Zine был Astro и сайт весил 150+кб, см Migration-from-Astro-to-Zine.md

Что сервер отдавал изначально:

• HTML (~15kb)
• Space Mono + Martian Mono woff2 (~40kb)
• Аватарка PNG (~2mb)
• Фавиконка PNG (~1mb)

на скрине уже немного заоптемайзенный, было хуже :skull:

Четыре запроса на страницу с контентом, который по факту весит нихрена. И это с keep-alive и HTTP/2 - setup один раз, но каждое новое соединение, каждая вкладка - всё заново.

План: всё в один HTML. Base64 инлайн всего. Ноль внешних запросов. Влезть в initcwnd со сжатием.

Шрифт

Самое жирное. 2 шрифта + bold-версии = 40kb.

По-хорошему кастомные шрифты нахуй не нужны. Но эстетика победила - решено оставить один, выпилив из файла всё кроме ASCII.

Инструмент: pyftsubset из fonttools. Выпиливаются нелатинские диапазоны, символы которых нет на сайте.

Итог: 4.2kb, в base64 - 5.7kb текста в HTML.

Аватарка

Пиксельарт, зарендерен в 400%, PNG с альфа-каналом. Жирно.

Шаколизатор, три цвета, PNG - 1.9kb. Конвертация в WebP - 702 байта.

Base64: 940 байт.

Фавиконка

Те же манипуляции. 199 байт в PNG (для мелких картинок он лучше WebP).

Base64: 268 байт.

JS

Анимированные кнопки, анимированный фон, пасхалка с анимацией. Всё для красоты. Реально полезного - кот наплакал.

Но функционал хотелось сохранить. Всё ушло в инлайн. ~4kb скриптов, без которых сайт работал бы не хуже. Но красиво.

Итог

До: 4 запроса, ~50kb

После: 1 запрос, 12kb gzip / 27kb raw

Влезает в initcwnd. Один TCP-пакет данных после рукопожатий - и сайт готов.

Дилемма инлайна

Инлайн всего - компромисс. Есть цена.

Кеширование

Шрифт в base64 внутри HTML - не кешируется. При переходе на другую страницу браузер качает его заново, потому что он часть HTML.

С отдельным файлом шрифт закешировался бы после первого раза. Вторая страница грузилась бы без него.

Когда что выбирать

Всё в одном HTML (base64 шрифты)
2 страницы по 14kb каждая
Каждая - 1 RTT
Но каждый раз жрёшь полные 14kb, даже если шрифт повторяется

HTML + отдельный шрифт
2 страницы по 8kb + шрифт 4kb отдельно
Первый заход: 2 запроса
Переходы: только 8kb, шрифт закеширован

В реальном интернете разницу между 14kb и 8kb не почувствовать - оба влезают в один initcwnd.

А вот делей между запросами - да.

Overhead

Инлайн весит чуть больше внешней зависимости - base64 добавляет ~33% к бинарным данным. Если ты и так не превышаешь initcwnd с внешними ресурсами - инлайн нахуй не нужен.

Он имеет смысл когда разница между “влез в один RTT” и “не влез” критична.

В случае sccl.cc разница была драматической: 4 запроса против 1, 50kb против 12kb. Оно того стоило.

Чо в итоге

14kb - не magic number. Это следствие архитектуры TCP, которая проектировалась для надёжности и честности, а не для скорости первой загрузки.

Понимание транспортного уровня даёт больше чем слепое следование “правилу 14kb”. Где-то нужен инлайн, где-то отдельные файлы с кешированием. Где-то 30kb raw с gzip - почти то же что 14kb без сжатия.

Но философия остаётся: чем меньше - тем быстрее. И чем меньше говна тащишь на сайт, тем больше уважения к пользователю.

Options for storing passwords:

1. In your head…
2. In a text file - secure
3. Google Chrome / Firefox / … - passwords stored who knows where
4. Bitwarden / 1Password / ProtonPass - okay, but you gotta pay, and data on someone else’s servers
5. Your own server - pog

Why not just run regular Bitwarden on a VPS?

You can. Bitwarden officially can be spun up with

docker run bitwarden/self-host

But:

• Need a VPS - from $5/mo
• Need Docker, need to make sure it doesn’t crash, need to update, need to backup
• For one person - overkill, but cool

What I want: free, nothing to admin, and it just works.

NodeWarden - Bitwarden-compatible server on Cloudflare Workers

NodeWarden - a fork of the Bitwarden server that runs directly on Cloudflare Workers.

So:

• Free (Workers - 100k requests/day)
• Nothing to admin
• Cloudflare updates the infrastructure itself
• Database - Cloudflare D1 (free: 5 GB, 5 million rows read/mo)

Compatible with all Bitwarden clients: browser extension, mobile app, CLI.

Deployment

Briefly:

1. Fork shuaiplus/nodewarden.
2. Clone locally: git clone <your-fork> && cd <your-repo> && npm install
3. Edit wrangler.toml: name, database_name etc.
4. D1 database is created automatically on first deploy - wrangler will spin up database_name from config.
5. Add JWT_SECRET: Dashboard → your worker → Settings → Variables. Any string >=32 chars, e.g. openssl rand -base64 32.
6. Deploy: Cloudflare Dashboard → Workers & Pages → Create → Pages → Connect to GitHub, select your fork. Cloudflare pulls the code, builds and deploys on every push to main. Build command - npm run build, worker deploys alongside Pages. No GitHub Actions needed.

Important: Cloudflare has a free plan, but to create R2 you need to attach a credit card.

NodeWarden has a deploy:kv mode that uses KV instead of R2 (file attachments). Database is D1 in both cases - nothing to attach, fully free. (if you can, you can attach an empty card, but the free limits are more than enough)

Is it safe?

overall: yes

In detail:

Under the hood it’s the standard Bitwarden end-to-end encryption scheme:

• Master password → KDF → master key (symmetric, AES-256). Lives only in the browser, never leaves.
• Master key → HKDF → encryption key - encrypts all passwords, TOTP keys, notes. The server only sees encrypted garbage.
• Additionally, an asymmetric key pair is generated: public key stored openly on the server, private key is encrypted with the encryption key and also sent to the server (needed for sync between devices).
• Master password → KDF → client hash - sent to the server. The server salts it again (server hash) and stores only that.
• The server cannot decrypt the vault. At all. It has no keys - only a hash for verifying the password at login.

The server only stores encrypted data. Even if the database is stolen - the attacker gets useless data that can’t be cracked without the master key.

Caveats

There are nuances:

Dependency on CF and GitHub

Cloudflare theoretically could modify your worker if they get hacked or cf itself gets compromised.

How realistic that is - depends on your paranoia and hygiene.

Features

NodeWarden supports most Bitwarden features. Here’s what’s available:

Send

Create a temporary link with text or a file attached.

Burns after time or number of views.

You can optionally password-protect the link. Sends can be manually revoked at any time.

Backup Center

Schedule automatic backups.
Backups are encrypted - without the master password they’re useless.

TOTP (Verification Codes)

Built-in TOTP generator - attach to a password and use instead of Google Authenticator or similar.

Passkeys

Replace the master password with a WebAuthn key.

2FA on login

Two-factor authentication at login.

But if someone steals the database + password, 2FA won’t help.

API Key

For Bitwarden CLI and automation.

Verdict?

Pros:

• Free
• Nothing to admin
• E2E encryption
• Bitwarden compatibility (any client)
• TOTP, Send, Passkeys, 2FA, Backup Center, API Key
• Cloud backups (WebDAV/S3)

Cons:

• Dependency on Cloudflare and GitHub
• No password sharing between users (each sees only their own vault)

A solid “set it and forget it” option for those who don’t want to pay for Bitwarden Premium, don’t want to give passwords to Google, and don’t want to admin a VPS.

Варианты хранить пароли:

1. В голове…
2. В текстовом файле - секурно
3. Google Chrome / Firefox / … - пароли хранятся хрен пойми у кого
4. Bitwarden / 1Password / ProtonPass - норм, но нада платить, и данные на чужих серверах
5. Свой сервер - имба

Почему не поставить обычный Bitwarden на VPS?

Можно. Bitwarden официально можно поднять через

docker run bitwarden/self-host

Но:

• Нада VPS - от 300-500 руб/мес
• Нада Docker, нада следить чтоб не упало, нада обновлять, нада бэкапить
• Для одного человека - жирнo, но круто

А хочется: бесплатно, ничего не админить, и чтоб работало.

NodeWarden - Bitwarden-совместимый сервер на Cloudflare Workers

NodeWarden - форк Bitwarden-сервера, который работает прямо на Cloudflare Workers.

То есть:

• Бесплатно ( Workers - 100к запросов/день )
• Ничего не надо админить
• Cloudflare сам апдейтит инфраструктуру
• База данных - Cloudflare D1 (бесплатно: 5 ГБ, 5 млн строк чтения/мес)

Совместим со всеми Bitwarden-клиентами: браузерное расширение, мобильное приложение, CLI.

Разворачивание

Кратенько:

1. Форкаешь shuaiplus/nodewarden.
2. Клонируешь локально: git clone <свой-форк> && cd <твоя-репа> && npm install
3. Правишь wrangler.toml: name, database_name и т.д.
4. D1-база создаётся автоматом при первом деплое - wrangler сам поднимет database_name из конфига.
5. Добавляешь JWT_SECRET: Dashboard → свой воркер → Settings → Variables. Любая строка >=32 символов, например openssl rand -base64 32.
6. Деплой: Cloudflare Dashboard → Workers & Pages → Create → Pages → Connect to GitHub, выбираешь форк. Cloudflare сам забирает код, билдит и деплоит при каждом пуше в main. Билд-команда - npm run build, воркер деплоится вместе с Pages. Никаких GitHub Actions не нужно.

Важный момент: у Cloudflare бесплатный план, но чтобы создать R2 - нужна привязка карты.

В NodeWarden есть режим deploy:kv, который вместо R2 (файловые вложения) юзает KV. База данных в обоих случаях D1 - ниче привязывать ненад, фулл бесплатно. (если есть возможностость, можно и привязать пустую карту, но лимитов и так с головой)

Это безопасно?

в целом: да

Подробнее:

Под капотом стандартная Bitwarden-схема end-to-end шифрования:

• Master password → KDF → master key (symmetric, AES-256). Живёт только в браузере, наружу не выходит никогда.
• Master key → HKDF → encryption key - им шифруются все пароли, TOTP-ключи, заметки. Сервер видит только зашифрованный мусор.
• Дополнительно генерится пара асимметричных ключей: public key хранится на сервере открыто, private key шифруется encryption key-ем и тоже улетает на сервер (нужен для синхра между устройствами).
• Master password → KDF → client hash - улетает на сервер. Сервер солит его ещё раз (server hash) и хранит только его.
• Сервер не может расшифровать vault. Вообще. У него нет ключей - только хэш для проверки пароля при логине.

Сервер хранит только зашифрованные данные. Даже если базу стащат - у злоумышленника будут только бесполезные данные, которые без мастер ключа он не вскроет.

Подводные камни

Есть нюансы:

Зависмость от Cf и GitHub

Со стороны Cloudflare теоретически может модифицировать твой worker, если ломанут git или сам cf.

Насколько это реально - вопрос к паранойе и твоей гигиене.

Фишки

NodeWarden поддерживает большинство фич Bitwarden. Вот чо есть:

Send

Можно создать временную ссылку, к которой можно приложить текст или файл.

Сгорает по времени или по количеству открытий.

Поверх ссылки можно навесить пароль (опционально). В любой момент Send можно отозвать вручную.

Backup Center

Можно настроить автоматические бекапы по расписанию.
Бекапы шифрованные, без мастер-пароля с ними ниче не сделают.

TOTP (Verification Codes)

Встроенный TOTP-генератор - можно приписать к паролю и юзать вместо условного Google Authenticator

Passkeys

Можно заменить мастер-пароль на ключ доступа (WebAuthn).

2FA на вход

Двухфакторка при логине.

Но если кто-то утащит базу+пароль, то 2fa уже не поможет.

API Key

Для Bitwarden CLI и автоматизации

Заебись?

Плюсы:

• Бесплатно
• Ничего не надо админить
• E2E шифрование
• Bitwarden-совместимость (любой клиент)
• TOTP, Send, Passkeys, 2FA, Backup Center, API Key
• Бекапы в облако (WebDAV/S3)

Минусы:

• Зависимость от Cloudflare и GitHub
• Нет шеринга паролей между юзерами (каждый видит только свой vault)

Хороший вариант “повставил и забыл” для тех, кто не хочет платить за Bitwarden Premium, не хочет отдавать пароли гуглу, и не хочет админить VPS.

Astro is a cool thing.
For quickly whipping up something nice it’s fine, but over time it started pissing me off:

Heavy runtime. To build a site you need Node.js, npm, node_modules at a hundred megabytes. For some static pages.

Complexity. Astro does everything: islands, ssr, endpoints, middleware. And I have a site with three pages: contacts, projects, peripherals - I don’t need much.

Alternatives?

I stumbled upon Zine.

Zine is an SSG in Zig. One binary, no dependencies.

Templates use SuperHTML - it’s valid html with templating added. No {{ }}, no Pug/Jade. Just html with attributes like :text, :if, :loop.

Content uses SuperMD - extended .md without needing to drop into html.

Migration process

Overall the migration was pretty simple - rewrite layouts from Astro to SuperHTML, port over existing scripts. The most tedious part is that astro uses its fucking .astro files with their weird mix of js and html, while SuperHTML is just html with extras.

Deploy

Zine is compiled into a standalone statically-linked binary. No dependencies, no runtimes - download and run. It’s not in npm, you can’t install it from any package manager. So you gotta deliver it to the runner somehow.

Options:

• download with curl on every build
• commit to the repository

First option is janky. Second sounds more reliable…

Stuff it in the repo

First thought - just commit zine to the repo so it builds out of the box:

cp /tmp/zine bin/zine
git add bin/zine && git commit
git push
> remote: error: File bin/zine is 152.19 MB; this exceeds GitHub's file size limit

And then you remember GitHub doesn’t allow files over 100 MB.

time to self-host git
maybe… later…

OK, rollback, pretend nothing happened. Check Zine docs - they recommend kristoff-it/setup-zine@v1 in GitHub Actions.

GitHub Actions

Throw kristoff-it/setup-zine@v1 into gh actions:

- uses: kristoff-it/setup-zine@v1
  with:
    version: v0.11.3
- run: zine release
- uses: cloudflare/wrangler-action@v3
  with:
    apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
    command: pages deploy public/ --project-name sccl-cc

Makes sense: action installs zine, zine builds, wrangler pushes to CF Pages.

The only secrets needed are CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID

(Permissions: Account → Cloudflare Pages → Edit).

Should’ve follow the docs, but I wanted to do it without gh actions.

Benefits?

Speed. Build in milliseconds instead of seconds.

Simplicity. No node_modules. No package-lock.json. No hundreds of dependencies. One binary, a content folder, a templates folder.

Control. I know every line of generated HTML. No hidden JS that Astro adds by default.

Downsides?

Zine is in beta.

Documentation is sparse in places. Community is small. If something breaks - you’re the first to notice.

But for a personal site it’s great.

One binary, a couple .smd files, one layout, and done.

How I ended up deploying this thing is described in How-to-ZINE-on-CF.md.

Astro - штука прикольная.
Для быстрого клепания чего-нить красивого неплох, но со временем он меня начал бесить:

Тяжёлый рантайм. Чтобы собрать сайт, надо тянуть Node.js, npm, node_modules на сотню мегабайт. Для одной статики.

Сложность. Astro умеет всё: острова, ssr, эндпоинты, middleware. А у меня сайтец на три страницы: контакты, проекты, периферия, многого ненадо.

Альтернативы?

Мне попался Zine.

Zine - это SSG на Zig. Один бинарник, без зависимостей.

Шаблоны на SuperHTML - это валидный html, в который добавили темплейтинг. Никаких {{ }}, никаких Pug/Jade. Просто html с атрибутами типа :text, :if, :loop.

Контент на SuperMD - расширенный .md без необходимости лезть в html.

Процесс переезда

В целом переехать достачно просто - над переписать лэйауты с Astro на SuperHTML, перекинуть уже имеющеся скрипты. Самое муторное эт, что astro юзает свои блядские .astro файлы со своей странной смесью js и html, а SuperHTML это просто html с плюхами.

Деплой

Zine скомпилен в standalone-бинарник со статической линковкой. Никаких зависимостей и рантаймов - скачал, запустил. В npm его нет, из пакетных менеджеров не установишь. Значит над как-то доставлять его на раннер.

Мысли:

• качать curl-ом при каждом билде
• закоммитить в репозиторий

Первый вариант - костыль. Второй звучит надёжнее…

Пихаем в репу

Первая мысль была - закоммитить zine в репозиторий, чтоб билдилось из коробки:

cp /tmp/zine bin/zine
git add bin/zine && git commit
git push
> remote: error: File bin/zine is 152.19 MB; this exceeds GitHub's file size limit

И тут вспоминается, что GitHub не пускает больше 100 МБ.

пора хостить свой git
может быть… потом…

Ок, откатываем, делаем вид, что ничего не было. Лезем в доку Zine - там рекомендуют kristoff-it/setup-zine@v1 в GitHub Actions.

GitHub Actions

Пихаем kristoff-it/setup-zine@v1 в gh actions:

- uses: kristoff-it/setup-zine@v1
  with:
    version: v0.11.3
- run: zine release
- uses: cloudflare/wrangler-action@v3
  with:
    apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
    command: pages deploy public/ --project-name sccl-cc

Всё логично: экшен ставит zine, zine билдит сайт, wrangler пушит на cf pages.

Из секретов нужны только CLOUDFLARE_API_TOKEN и CLOUDFLARE_ACCOUNT_ID

(права Account → Cloudflare Pages → Edit).

над было сразу по доке следовать, но хотелось изначально без gh actions делать

Плюшки?

Скорость. Билд за миллисекунды вместо секунд.

Простота. Нет node_modules. Нет package-lock.json. Нет сотен зависимостей. Один бинарник, папка с контентом, папка с шаблонами.

Контроль. Я знаю, что в каждой строчке сгенерированного HTML. Никакого скрытого JS, который Astro добавляет по умолчанию.

Минусы?

Zine в бете.

Документация местами бедная. Сообщество маленькое. Если что-то сломалось - ты первый, кто это заметил.

Но для личного сайта это топ.

Один бинарник, пара .smd-файлов, один лэйаут и готово.

Guts and their cost

• 1x Dongle Nordic Nrf52840 with Oled screen :bongocat: - 1500 RUR
• 2x Controllers, Chinese product in the form of nice!nano v2, also on nrf52840 - 1300 rubles
• 58x Kailh 1350 hotswap sockets - ~500 RUR
• 58x Kailh Deep sea silent low profile switches - 2000 RUR
• 58x diodes 1N4148 - 100 rub.
• 2 batteries 503450 1000mah - 200 rubles (wholesale)
• 2x toggle switches - 10 rubles (wholesale)
• screws-threads-wires - some pennies, because… are bought only in hundreds-thousands
• connectors for batteries - 2 rubles (wholesale)
• a couple of hundred grams of PETG plastic - 200 rubles?
  == ~<6000 rub.

• many man-hours of work on the development and assembly of various tools and equipment

Crap without a pcb - hardcore handwired
In general, I don’t see any point in making a board at all for mechanics; this is done only in large-scale production, because it’s faster and cheaper, but it doesn’t mean it’s better and of higher quality. Without a board, you can also screw up any keyboard shape, change the height and tilt of the buttons, etc.

Here is ZMK software
Presumably the charge should last up to several months of daily work-gaming for 15 hours a day. (the calculator is generally hesit for 10 months, but let’s be realistic)

Seriously. A keyboard is what we interact with a computer through. Every day. For hours. For years. And the input system is still built on the assumption that everyone uses QWERTY.

Switched to Colemak? Hotkeys in games are broken. Switched to Rulemak? Aseprite has no idea what’s going on. Using non-QWERTY in some old program? Welcome to hell.

And it’s not a bug. It’s a feature. An anglocentric feature that’s 40 years old.

How it should work

There’s hardware. There are keys. Each key has a physical position.

A scan code is simply the number of that position. Pressed the key in the top left corner - got a scan code. Doesn’t matter what letter is painted on it. Doesn’t matter what language. It’s just “button number 16”.

The right approach: a program (game, editor, whatever) listens to scan codes. Hotkey Ctrl+Z is bound to the physical position of the Z key - not the Z symbol, not the VK_Z virtual code, but the scan code. Then the hotkey works the same in any layout.

What went wrong: somewhere in the late 80s, the industry decided it was more convenient to work with symbols and virtual codes. Because “well everyone uses QWERTY anyway, what’s the big deal”.

And ever since, every layer of abstraction added on top of scan codes has created problems for anyone not on QWERTY.

PS/2 keyboards by the way support three scan code sets: XT (set 1), AT (set 2), and 3270 (set 3). Modern keyboards send set 2, the motherboard controller translates to set 1. Live with this knowledge.

Windows: three layers of pain

Keyboard input on Windows goes through three levels:

scan_code -> virtual_key -> Symbol

Scan code - the only sane thing. Assigned by the keyboard driver, doesn’t change with layout. Modern drivers can remap the matrix, but that’s rare.

Virtual key - useless bullshit. Appeared back in Windows 3.1. The problem then was: there’s an app written for QWERTY, and a user in France is on AZERTY. Hotkeys don’t work. Microsoft’s solution: let’s create a layer that maps physical keys to their “QWERTY equivalent”. Like “what letter would be on this key if the layout were QWERTY”.

Originally the idea was reasonable. But vk should have died with Win16 applications.

It didn’t die.

It’s still in WinAPI. GetKeyState(VK_CONTROL), WM_KEYDOWN with VK codes. All native Windows software sits on VK. And you can’t just ignore VK because the entire WinAPI works through it.

Symbol - actual characters according to the layout. This part’s fine - you press a key with Shift/AltGr applied, you get a letter.

The problem is there are two abstraction layers between scan code and the application. And every app picks its own.

Games: every engine jerks off in its own way

DirectInput

This fucking outdated DirectInput maps by VK.

It’s an API from the 90s. Microsoft themselves declared it deprecated back in 2005. They recommend XInput for gamepads and Raw Input for keyboards.

But it’s still alive. Some games are still on it. Everything on DirectInput is garbage for non-QWERTY layouts.

Unity

Fucking Unity invented their own Input Manager. Input.getKey is anally tied to Symbol.

That means a hotkey is bound not to a key, but to whatever letter that key produces in the CURRENT layout. Switch the layout - hotkeys are gone.

Supposedly they updated the input system to the “New Input System”. Now you can grab keys through scan codes like Keyboard.current.wKey. But shit still happens with custom layouts in some situations anyway.

So they sort of fixed it, but not completely. Classic.

Unreal Engine

In UE, if the dev doesn’t slam that “use scan code” checkbox - input will be through VK.

Default is VK. Meaning every Unreal game is potentially broken. Depends on whether the dev gave a shit.

Source Engine

But grandpa GabeN in Source (TF2, CS2, Portal…) uses scan codes for movement input.

And it just works. On any layout. Without rebinding.

no matter how much you hate Valve - they do know how to do some things right.

Good examples

Besides Source, there are decent folks out there.

Minecraft. Up until somewhere around 1.9-1.12 (don’t remember exactly) Minecraft had different input code - everything was bound to VK.

So if your layout wasn’t QWERTY (and in some layouts the vk differs, like French and German) - you had to rebind. Every time. Every update.

Then somewhere around 1.12+ they rewrote it to scan codes. And everything started working beautifully. Because the physical W key is always the physical W key, no matter what letter your layout says it is.

minecraft bedrock can go fuck itself, we’ve got DirectInput yo

Software: Aseprite and the rest

And fucking Aseprite, goddammit, uses Symbol.

You’re drawing pixel art. You switch to a Russian layout (or any non-QWERTY). And the hotkeys fly off to god knows where.

Because B in the Russian layout is И. And Aseprite thinks “aha, the И key was pressed, let me check my hotkey table… nope, no hotkey for И”.

Even though physically you pressed the same key.

Lots of programs do this. Aseprite is just the most painful example - its whole workflow is built on hotkeys.

Everything else goes through WinAPI - meaning VK. And VK maps to the “QWERTY equivalent”. On some non-QWERTY layouts (French AZERTY, German QWERTZ) this equivalent differs from actual QWERTY. And hotkeys go to shit.

Decent folks use scan codes. They’re the minority.

Linux: its own set of rakes

Linux also shat the bed, and arguably even harder.

For starters, there are three abstraction layers before you get a symbol.

Hardware scan code. The keyboard (PS/2 or USB HID) sends a raw scan code. The kernel receives it.

linux_keycode. The kernel digests the scan code into things like KEY_Q, KEY_W, KEY_E. This is no longer a physical number, it’s a “QWERTY position”. At this level you’ve already lost the pure scan code.

That is, the Linux kernel immediately makes an anglocentric assumption.

XKB. X Keyboard Extension takes whatever the kernel shat out (KEY_Q, KEY_W…) and shits out its own positions: <AD01>, <AD02> … <AB01>, <AB02>.

And XKB maps these coordinates directly to symbols (Keysyms). Like <AD01> = q, and in the Russian layout = Cyrillic_shorti (й).

The Linux problem is that if a program listens to linux_keycode directly (and many do, especially old X11 programs and some games through SDL), you get the same problems as with VK on Windows.

But if a program listens to XKB Keysyms - it gets the final characters. And if it binds hotkeys to characters rather than scan codes - broken again.

What to do

Programmers: bind input to scan codes. Always. A key’s physical position doesn’t change with the layout.

Game devs: take a look at Source(Quake(Doom)). It was all figured out 30+ years ago.

Non-QWERTY users: suffer. Or file bug reports tagged “keyboard layout”. Or build your own tools to work around this crap.

Maybe, someday, operating systems will start supporting languages other than English.

But apparently not yet.

Кишки и их себестоимость

• 1х Донгл Nordic Nrf52840 с Oled экраном :bongocat: - 1500 руб
• 2x Контроллеры, китай поделие в форме nice!nano v2, тоже на nrf52840 - 1300 руб
• 58х Kailh 1350 hotswap сокеты - ~500 руб
• 58х Свитчи Kailh Deep sea silent low profile - 2000 руб
• 58х диоды 1N4148 - 100 руб
• 2х аккумуляторы 503450 1000mah - 200 руб (оптом)
• 2x тумблера - 10 рублей (оптом)
• винтики-резьбы-провода - какие-то копейки, т.к. покупаются только сотнями-тысячами
• коннекторы для акб - 2 руб (оптом)
• пару сотен грамм PETG пластика - 200 руб?
  == ~<6000 руб

• много человеко-часов работы на разработку и сброку, разных инструментов и оборудования

Поделие без платы - хардкорный handwired
В целом в механиках не вижу смысла вооще изготавливать плату, это делают только при масштабном производстве, ибо так тупа быстрее и дешевле, но не значит лучше и качественнее. Без платы так же можно нахуячить любую форму клавы, менять высоту и наклон кнопок и т.д

Софт туты ZMK
Предположительно заряда должно хватать до нескольких месяцев ежедневного работы-гейминга по 15ч в сутки. (калькулятор вообще под 10 месяцев гессит, но будем реалистами)

Серьёзно. Клавиатура - это то, через что мы взаимодействуем с компом каждый день. Часами. Годами. И система ввода до сих пор завязана на предположении что все сидят на QWERTY.

Поменял раскладку на Colemak? Хоткеи в играх сломались. Переключился на Rulemak? Aseprite не понимает что происходит. Юзаешь не-QWERTY в какой-нибудь старой проге? Добро пожаловать в ад.

И это не баг. Это фича. Англоцентричная фича, которой 40 лет.

Как должно работать

Есть железо. Есть кнопки. У каждой кнопки есть физическая позиция.

Scan code - это просто номер этой позиции. Нажал клавишу в левом верхнем углу - получил scan code. Не важно какая там буква нарисована. Не важно какой язык. Это просто “кнопка номер 16”.

Правильный подход: программа (игра, редактор, что угодно) слушает scan codes. Хоткей Ctrl+Z привязан к физической позиции кнопки Z - не к символу Z, не к виртуальному коду VK_Z, а к scan code. Тогда при любой раскладке хоткей работает одинаково.

Что пошло не так: где-то в конце 80-х индустрия решила что удобнее работать с символами и виртуальными кодами. Потому что “ну все же на QWERTY сидят, чо там”.

И с тех пор каждый слой абстракции, добавленный поверх scan code, создавал проблемы для всех кто не на QWERTY.

PS/2 клавиатуры кстати поддерживают три сета scan codes. XT (set 1), AT (set 2), и 3270 (set 3). Современные клавы шлют set 2, контроллер на материнке транслирует в set 1. Живити с этой информацией.

Windows: три слоя боли

Ввод с клавиатуры в Windows проходит три уровня:

scan_code -> virtual_key -> Symbol

Scan code - единственная адекватная вещь. Присваивается драйвером клавиатуры, не меняется от раскладки. В современных дровах можно ремапить матрицу, но это редкость.

Virtual key - бесполезное говно. Появилось ещё в Windows 3.1. Тогда проблема была такая: есть приложение написанное под QWERTY, а юзер во Франции сидит на AZERTY. Хоткеи не работают. Решение Microsoft: давайте создадим прослойку которая мапит физическую кнопку на “QWERTY-эквивалент”. Типа “какая буква была бы на этой кнопке если бы раскладка была QWERTY”.

Изначально идея была здравая. Но vk должен был умереть вместе с Win16 приложениями.

Он не умер.

Он в WinAPI до сих пор. GetKeyState(VK_CONTROL), WM_KEYDOWN с VK-кодами. Весь нативный Windows-софт сидит на VK. И ты не можешь просто взять и игнорить VK, потому что весь WinAPI через него работает.

Symbol - уже конкретные символы в соответствии с раскладкой. Тут всё ок - нажал кнопку с учётом Shift/AltGr, получил букву.

Проблема в том что между scan code и приложением два уровня абстракции. И каждое приложение выбирает свой.

Игры: каждый дрочит как хочет

DirectInput

Ебучий устаревший DirectInput мапит по VK.

Это API из 90-х. Microsoft сами признали его устаревшим ещё в 2005. Рекомендуют XInput для геймпадов и Raw Input для клавиатур.

Но он до сих пор жив. Некоторые игры до сих пор на нём. Всё что на DirectInput - всё говно для не-QWERTY раскладок.

Unity

Сраный Unity придумал свой Input Manager. Input.getKey анально привязан к Symbol.

То есть хоткей привязан не к кнопке, а к букве которую эта кнопка вводит в ТЕКУЩЕЙ раскладке. Переключил раскладку - хоткеи улетели.

Вродь они обновили систему инпута на “New Input System”. Теперь можно хапать клавиши через scan codes типа Keyboard.current.wKey. Но серавно в каких-то ситуациях происходит хуйня с кастомными раскладками.

То есть они типа починили, но не до конца. Классика.

Unreal Engine

В UE если разраб не въебнёт галочку “use scan code” - инпут будет через VK.

По дефолту VK. То есть каждая игра на Unreal потенциально сломана. Зависит от того, заморачивался ли разраб.

Source Engine

А вот дядушка Габен в сурсе (TF2, CS2, Portal…) юзает scan codes для ввода движения.

И оно просто работает. На любой раскладке. Без перенастроек.

сколько не хейти valve - что-то да хорошее делать они умеют.

Хорошие примеры

Кроме сурса есть нормальные ребята.

Minecraft. Где-то до 1.9-1.12 (точно не помню) в майне был другой код инпута - всё привязывалось к VK.

То есть если у тебя раскладка не QWERTY (а в некоторых раскладках vk отличается, например во французской и немецкой) - тебе приходилось ребиндить. Каждый раз. При каждом обновлении.

Потом в районе 1.12+ переписали на scan codes. И всё стало пиздато работать. Потому что физическая кнопка W - это всегда физическая кнопка W, не важно какая там буква в твоей раскладке.

в миникрафт бедроке пошли нахуй, у нас DirectInput йоу

Софт: Aseprite и остальные

А ебучий Aseprite блять по Symbol хуярит.

Ты рисуешь пиксельарт. Переключился на русскую раскладку (или любую другую не-QWERTY). И хоткеи улетают куда-то хуй пойми куда.

Потому что B в русской раскладке это И. И Aseprite думает “ага, нажата кнопка И, смотрю в своей таблице хоткеев… а там нет хоткея на И”.

Хотя физически ты нажал ту же кнопку.

Так многие проги. Aseprite просто самый больной пример - в нём работа завязана на хоткеи.

В остальном весь софт ходит через WinAPI - соответственно VK. А VK мапится на “QWERTY-эквивалент”. На некоторых не-QWERTY раскладках (французская AZERTY, немецкая QWERTZ) этот эквивалент отличается от QWERTY. И хоткеи летят лесом.

Нормальные ребята юзают scan codes. Их меньшинство.

Linux: свои грабли

В Linux тоже насрали, и кабуда даже сильнее.

Начнём с того, что там три слоя абстракции до символа.

Аппаратный scan code. Клавиатура (PS/2 или USB HID) шлёт сырой scan code. Ядро получает.

linux_keycode. Ядро переваривает scan code в условные KEY_Q, KEY_W, KEY_E. Это уже не физический номер, а “QWERTY-позиция”. То есть на этом уровне ты уже потерял чистый scan code.

То есть Linux kernel сразу же делает англоцентричное предположение.

XKB. X Keyboard Extension берёт что ядро высрало (KEY_Q, KEY_W…) и высерает свои позиции: <AD01>, <AD02> … <AB01>, <AB02>.

И уже эти координаты XKB мапит напрямую в символы (Keysyms). Типа <AD01> = q, а в русской раскладке = Cyrillic_shorti (й).

Проблема линукса в том, что если прога слушает linux_keycode напрямую (а многие так делают, особенно старые X11 проги и некоторые игры через SDL), ты получаешь те же проблемы что и с VK в Windows.

Но если прога слушает XKB Keysyms - она получает уже окончательные символы. И если она привязывает хоткеи к символам а не к scan codes - опять слом.

Что делать

Программистам: биндите инпут на scan codes. Всегда. Физическая позиция кнопки не меняется от раскладки.

Разрабам игр: загляните в Source(Quake(Doom)). Всё за вас придумали 30+ лет назад.

Пользователям не-QWERTY раскладок: страдать. Или писать баг-репорты с тегом “keyboard layout”. Или делать свои инструменты для обхода этой хуйни.

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

Но видимо пока рано.

Sound comparison can be seen in the video

Tierlist

🔴 - Linear

🟡 - Tactile

🔵 - Clicky

Description of each

[LINEARS]

• Outemu Silent White - The simplest quiet switch, a little sandy, but for the first generation it will do if you have an ultra low-budget build.
• Outemu Silver - Standard slag, fast, with short stroke.
• Outemu Black - Standard slag, weighted spring.
• Outemu Red - Standard slag, basic.
• Outemu Silent Peach V1 - It was ok, but now there is something better. Quiet, soft.
• Outemu Silent Peach V2 - Good ultra-budget quiet switch.
• Outemu Cold Plum - Winter collection. Full nylon body, short stroke, heavy spring. Thick thocky sound.
• Outemu Pink Lotus - Summer collection. Lightweight, short stroke, smooth.
• Outemu Milk Peach - Budget regular switch, nice sound, but Cream and Jade are better.
• Outemu Bai Lan - Average.
• Outemu Hanny - Long-pole stem. Loud clacky switch (lego movie sound).
• Outemu Lanny - Similar to Hanny, but a little more balanced and ordinary.
• Outemu Silent Ocean - Not a bad quiet switch.
• Outemu Crystal Linear - Completely made of polycarbonate. Dry and rattling.
• Outemu Dustproof Silver - Slightly better than regular silver, but still so-so.
• Outemu Cream Pink - Well lubricated, buttery action, deep sound (but Jade is better).
• Outemu Jade Pink - A cooler version of Cream Pink, with a faster spring.

[TACTILES]

• Outemu Brown - Absolute crap. There is no tactility, it feels like a dirty sand ruler with a ringing spring.
• Outemu Orange - A little heavier than Brown, but the same dry trash with a ringing sound.
• Outemu Purple - Old heavy tactile. The bump is sharp and unpleasant, the spring rings harshly on return.
• Outemu Red Panda - Passable clone of Holy Panda. A rounded bump at the start, but without manual lubrication it’s a so-so idea.
• Outemu Maple Leaf - Not a bad ringing tactile. The bump is clear, feels fast, and has a clacky sound.
• Outemu Milk Tea - Budget average. Due to the milky casing, the sound is a little softer, but the tactility is weak.
• Outemu Silent Jade Yellow - Top silent tactile device. A clear bump at the start, not wadded at all, lubricated normally. Close to Gazzew Boba u4, but softer.
• Outemu Cream Yellow - Tactile analogue of Cream Pink. Good lubrication, soft dull sound, pleasant running. Also close to u4.
• Outemu Silent Tom - Old silent tactile. The hillock is indistinct and blurred, no longer relevant.
• Outemu Silent Grey - Ancient cotton shit. There is almost no bump, when pressed there is a complete feeling of rubber.
• Outemu Silent Lemon V1 - Was a popular quiet switch, but is very sandy.
• Outemu Silent Lemon V2 - Work on bugs V1. It has become much smoother, normal quiet tactile.

[CLICKIES]

• Outemu Blue, Outemu Green, Outemu Gold, Outemu Ocean Clicky, Outemu Spring Breeze, Outemu Milk Blue, Outemu Jerry Clicky, Outemu Cream Blue, Outemu Jade Blue - Total shit without exception. Due to the cheap design of the Click Jacket, everything inside is loose and rattling. A nasty plastic crunch instead of a normal click.

Звуковое сравнение можно посмотреть в видосике

Тирлист

🔴 - Linear

🟡 - Tactile

🔵 - Clicky

Описание каждого

[LINEARS]

• Outemu Silent White - Простейший тихий свитч, немного песочит, но для первого поколения сойдёт, если ультра низкобюджетная сборка.
• Outemu Silver - Стандартный шлак, быстрый, с укороченным ходом.
• Outemu Black - Стандартный шлак, утяжелённая пружина.
• Outemu Red - Стандартный шлак, базовый.
• Outemu Silent Peach V1 - Был норм, но сейчас есть лучше. Тихий, мягкий.
• Outemu Silent Peach V2 - Хороший ультрабюджет тихий свитч.
• Outemu Cold Plum - Winter коллекция. Фулл нейлоновый корпус, укороченный ход, тяжелая пружина. Плотный thocky звук.
• Outemu Pink Lotus - Summer коллекция. Лёгкий, укороченный ход, плавный.
• Outemu Milk Peach - Бюджетный обычный свитч, приятный звук, но Cream и Jade лучше.
• Outemu Bai Lan - Середнячок.
• Outemu Hanny - Long-pole стем. Громкий clacky свитч (lego movie sound).
• Outemu Lanny - Похож на Hanny, но чуть сбалансированнее и обычнее.
• Outemu Silent Ocean - Неплохой тихий свитч.
• Outemu Crystal Linear - Полностью из поликарбоната. Сухой и дребезжит.
• Outemu Dustproof Silver - Чуть лучше обычного сильвера, но все равно так себе.
• Outemu Cream Pink - Хорошо смазан, маслянистый ход, глубокий звук (но Jade лучше).
• Outemu Jade Pink - Более крутая версия Cream Pink, с быстрой пружиной.

[TACTILES]

• Outemu Brown - Абсолютное говно. Тактильности нет, ощущается как грязный песочный линейник со звенящей пружиной.
• Outemu Orange - Чуть тяжелее, чем Brown, но такой же сухой хлам со звоном.
• Outemu Purple - Старый тяжелый тактильник. Бугор резкий and неприятный, пружина жестко звенит на возврате.
• Outemu Red Panda - Проходной клон Holy Panda. Округлый бугор на старте, но без ручной смазки так себе затея.
• Outemu Maple Leaf - Неплохой звонкий тактильник. Бугор четкий, ощущается быстрым, clacky звучание.
• Outemu Milk Tea - Бюджетный средняк. Из-за молочного корпуса звук чуть мягче, но тактильность слабая.
• Outemu Silent Jade Yellow - Топовый тихий тактильник. Четкий бугор на старте, вообще не ватный, смазан нормально. Близок к Gazzew Boba u4, но мягче.
• Outemu Cream Yellow - Тактильный аналог Cream Pink. Хорошая смазка, мягкий глухой звук, приятный ход. Тоже близок к u4.
• Outemu Silent Tom - Старый тихий тактильник. Бугор невнятный и размытый, уже не актуален.
• Outemu Silent Grey - Древнее ватное говно. Бугра почти нет, при нажатии полное ощущение резины.
• Outemu Silent Lemon V1 - Был популярным тихим свитчем, но сильно песочит.
• Outemu Silent Lemon V2 - Работа над ошибками V1. Стал гораздо плавнее, нормальный тихий тактил.

[CLICKIES]

• Outemu Blue, Outemu Green, Outemu Gold, Outemu Ocean Clicky, Outemu Spring Breeze, Outemu Milk Blue, Outemu Jerry Clicky, Outemu Cream Blue, Outemu Jade Blue - Тотальное говно без исключений. Из-за дешевой конструкции Click Jacket внутри все люфтит и дребезжит. Мерзкий пластиковый хруст вместо нормального клика.

It seems surprising how many spammers are on Discord. Their sheer numbers have spawned the 1.jpg, 2.jpg, 3.jpg, 4.jpg @everyone @here meme

And then you dig into the topic and it turns out that absolutely any unauthorized file read access lets you steal someone’s session with a single token grep. No problem at all.

Not “you need to inject into the process”. Not “you need to bypass OS-level protection”. Just read a file.

What is a token?

Very roughly, in Discord:

login + password + 2fa
        ↓
Discord issues a token (hash based on some data)
        ↓
the token becomes your session

Then the client sends this token to the server with every request:

“it’s still me”

Server:

“ok, come in”

Standard scheme. That’s how OAuth2, JWT, bearer tokens work. The model itself is fine - a token instead of a password, can be revoked server-side.

The problem isn’t the token. The problem is where it sits.

Where the token is stored

Discord is built on Electron. Electron is a framework for desktop apps using HTML/CSS/JS. Basically a browser without an address bar.

Discord stores the token in Local Storage. Technically it’s a LevelDB database sitting in the user’s home directory:

~/.config/discord/Local Storage/leveldb/

Or on Windows:

%APPDATA%/discord/Local Storage/leveldb/

And the token sits there in plaintext.

Not encrypted. Not in the OS keychain. Just a string in a database. Any program running as your user can read this file.

And now the funniest part: Electron, which Discord is built on, has had a built-in safeStorage API since 2019.

It can encrypt data using OS-level mechanisms:

• macOS - Keychain Access. Protection from other users AND from other applications.
• Windows - DPAPI (Data Protection API). Encrypts with a key tied to the user account. Protection from other users.
• Linux - kwallet, gnome-libsecret, or freedesktop Secret Service. Depending on your DE.

So the tool for proper secret storage is right there in Electron, out of the box. No need to install anything separately. No need to write your own crypto. Just call safeStorage.encryptString(token).

Discord doesn’t do this.

For 6 years now.

What happens if the token is stolen?

Literally nothing interesting happens:

You take the token.

Feed it to another client.

T H A T ’ S I T …

: You’re already inside the account.

• No login.
• No password.
• No 2FA.
• No SMS.
• No passkey.
• No push notifications.
• No confirmations.
• No alerts about a new login.

The new login isn’t even registered as new. The old session simply “moves” to a different machine.

The only thing you might notice is getting logged out of your device. And only if someone’s already logged in with that token, without leaving it for a rainy day.

Is it easy to steal?

Yes.

On Windows it works exactly the same. Any .exe you download claiming to be “game cheats” or “free nitro” can read the file and send the token to the attacker’s server.

No exploits. No zero-day vulnerabilities. Just open() on a file that Discord itself placed in the home directory.

How Discord COULD have done it

There are a fuckton of options. All standard, all industry-wide:

• safeStorage in Electron - available since 2019, used by other Electron apps (Signal Desktop, 1Password, Bitwarden)
• Store secrets through OS keychain directly
• Access confirmation for secrets (biometrics, master password)
• Device fingerprint + token binding to hardware
• A separate key generated on-device at first login
• Security alerts on sudden environment changes (new IP, new OS, new hardware)
• Device-based sessions with new device confirmation

Yes, all of this can also be bypassed with full access to the machine.

But between:

“read a file”

and

“inject into a process, bypass system dialogs, spoof the environment”

there’s a massive gap.

Right now the attacker only needs the most primitive access - read permissions on files in the home directory. Meaning literally any running program.

With safeStorage, the attacker would need to either inject into the Discord process, or decrypt DPAPI/Keychain (which requires privilege escalation or stealing the master password).

It doesn’t make the attack impossible. But it raises the bar from “script kiddie with grep” to “targeted attack with specific tools”.

And right now?

Right now the cost of an attack looks roughly like this:

download suspicious crap
        ↓
it reads a file
        ↓
your session is stolen: "1.jpg, 2.jpg, 3.jpg, 4.jpg @everyone @here"

And it doesn’t matter that you have 2FA. Doesn’t matter that your password is complex. The file is open to all programs running as your user.

If Discord can’t

An option - log into Discord from a dedicated user account.

So that only that user has read permissions on the session database. Barring internal exploits in the Discord app itself - the chance of anything getting stolen is minimal.

On Linux this is easy out of the box - the permission hierarchy is baked in since the system’s birth.

On Windows it’s also possible, but security isn’t as strong: permissions were bolted on as a hack only with the Vista release, and plenty of software still bypasses them.

But still better than leaving the file open to everyone, which Discord for some unfathomable reason couldn’t protect itself.

This protection layer is implemented in my NixOs config

you can check your own discord right now: go to ~/.config/discord/Local Storage/leveldb/ and run grep -r 'mfa\.[a-zA-Z0-9_-]\{20,\}' . - you’ll probably find your token.

Казалось бы удивительно, чо так много спамеров в дискорде. Они своим количеством уже породили мем 1.jpg, 2.jpg, 3.jpg, 4.jpg @everyone @here

А потом копаешь тему и оказывается что абсолютно любой несанкционированный доступ к чтению файлов позволяет без проблем украсть твою сессию одним grep-ом токена.

Не “надо внедриться в процесс”. Не “надо обойти OS-level защиту”. Просто прочитать файл.

Что такое токен?

Очень грубо, в дискорде:

login + password + 2fa
        ↓
Discord выдаёт токен (хэш на основе каких-то данных)
        ↓
токен становится твоей сессией

Дальше клиент кидает этот токен на сервер при каждом запросе:

“это всё ещё я”

Сервер:

“ок, входи”

Стандартная схема. Так работает OAuth2, JWT, bearer tokens. Сама по себе модель норм - токен вместо пароля, можно отозвать серверно.

Проблема не в токене. Проблема в том, где он лежит.

Где хранится токен

Discord построен на Electron. Electron - это фреймворк для десктопных приложений на HTML/CSS/JS. По сути это браузер без адресной строки.

Discord хранит токен в Local Storage. Технически это LevelDB база, которая лежит в домашней директории пользователя:

~/.config/discord/Local Storage/leveldb/

Или на Windows:

%APPDATA%/discord/Local Storage/leveldb/

И токен лежит там в plaintext.

Не зашифрованный. Не в OS keychain. Просто строка в базе данных. Любая программа, запущенная от твоего пользователя, может прочитать этот файл.

А теперь самое смешное: Electron, на котором построен Discord, с 2019 года имеет встроенный API safeStorage.

Он умеет шифровать данные через OS-level механизмы:

• macOS - Keychain Access. Защита от других пользователей И от других приложений.
• Windows - DPAPI (Data Protection API). Шифрует ключом, привязанным к учётке пользователя. Защита от других пользователей.
• Linux - kwallet, gnome-libsecret, или freedesktop Secret Service. В зависимости от DE.

То есть инструмент для нормального хранения секретов есть прямо в Electron из коробки. Его не надо ставить отдельно. Не надо писать свою криптографию. Просто вызвать safeStorage.encryptString(token).

Discord этого не делает.

Уже 6 лет как.

А если токен украсть?

То буквально ничего интересного не происходит:

Берёшь токен.

Подсовываешь его другому клиенту.

В С Ё…

: Ты уже внутри аккаунта.

• Без логина.
• Без пароля.
• Без 2FA.
• Без SMS.
• Без passkey.
• Без push-уведомлений.
• Без подтверждений.
• Без алертов о новом входе.

Новый логин вообще не регистрируется как новый. Старая сессия просто “переезжает” на другую машину.

Всё что можешь заметить - так это что разлогинило с твоего устройства. И то при условии что с этого токена уже кто-то зашёл, не оставив на чёрный день.

А чо, легко украсть?

Да.

На Windows работает ровно так же. Любой .exe качающий “читы для игры” или “бесплатный нитро” может прочитать файл и отправить токен на сервер злоумышленника.

Никаких эксплойтов. Никаких уязвимостей нулевого дня. Просто open() на файл, который Discord сам положил в домашнюю директорию.

Как Discord МОГ бы сделать

Вариантов дохуя. Все стандартные, все индустриальные:

• safeStorage в Electron - доступен с 2019, юзают другие Electron-приложения (Signal Desktop, 1Password, Bitwarden)
• Хранение секретов через OS keychain напрямую
• Подтверждение доступа к секрету (биометрия, master password)
• Fingerprint устройства + привязка токена к железу
• Отдельный ключ, генерируемый на устройстве при первом входе
• Security alerts при резкой смене окружения (новый IP, новая OS, новое железо)
• Device-based сессии с подтверждением нового устройства

Да, всё это тоже можно обходить при наличии full access к машине.

Но между:

“прочитать файл”

и

“внедриться в процесс, обойти системные диалоги, подделать окружение”

лежит огромная пропасть.

Сейчас атакующему достаточно самого примитивного доступа - права на чтение файлов в домашней директории. То есть вообще любой запущенной программы.

С safeStorage атакующему пришлось бы либо внедряться в процесс Discord, либо расшифровывать DPAPI/Keychain (что требует повышения привилегий или кражи мастер-пароля).

Это не делает атаку невозможной. Но поднимает планку с “скрипткидди с grep-ом” до “таргетированной атаки со специфическими инструментами”.

А сейчас?

Сейчас цена атаки выглядит примерно так:

скачал подозрительную фигню
        ↓
она прочитала файл
        ↓
твою сессию угнали: "1.jpg, 2.jpg, 3.jpg, 4.jpg @everyone @here"

И пофиг что у тебя 2FA. Пофиг что сложный пароль. Файл открыт для всех программ, запущенных от твоего пользователя.

Если Discord не может

Как варик - логиниться в Discord со специально выделенного пользователя.

Чтоб права на чтение базы с сессией были только у него. При отсутствии внутренних эксплойтов в приложении Discord - шанс что у тебя что-то угонят минимальный.

На Linux это легко сделать из коробки - иерархия прав там нормальная с рождения системы.

На Windows в целом тоже можно, но безопасность не так велика: права появились как костыль лишь с релизом Vista, и до сих пор много софта работает в обход них.

Но всё лучше, чем оставлять файл открытым для всех, который Discord сам защитить по какой-то неведомой причине не смог.

Такая защитная прослойка имплементирована в моём NixOs config

можешь прям щас проверить свой discord: зайди в ~/.config/discord/Local Storage/leveldb/ и сделай grep -r 'mfa\.[a-zA-Z0-9_-]\{20,\}' . - скорее всего найдёшь свой токен.

A.K.A.

Long way to dream

In short…

I have long had a desire to build a custom keyboard from scratch…
This writing is essentially my shitpost (Idk what the fuck:: I love writing letters)
I’ll dump my thoughts on this project here, if you can call it that. (sort of like an overkill job, maybe it’s possible)

Whatamhow

It is known that the topic of analog keyboards, mainly based on Hall-Effect sensors, has been popular in the keyboard market for the last few years.
I don’t see any point in listing the goodies, they are obvious.
And one of the minuses is the fucking energy consumption of HE keyboards compared to mechanical ones.
Which greatly complicates the assembly of a wireless keyboard…

For many, it may seem that wireless is useless shit, useless to anyone.
Until some time I thought so myself, sitting on a staggered 2 kg piece of aluminum with buttons.
But then I found myself in the hands of a split keyboard without a single wire.
: turned on 2 halves, shoved the USB dongle into the computer and you work
holds a charge for 3 months with 15 hours of daily use with 1500mAh batteries in each half (hule mechanics)
And it turned out to be so convenient that I can no longer imagine a keyboard with wires.

That’s why I look towards tmr, because he eats 8 times less than he
Although there must be pitfalls with it in the form of an unstable Vcc, which can spoil their accuracy, which is crap in comparison with he (well, in fact, in fact, they are stupidly less noisy, they don’t really suck in terms of accuracy)

Sobsna what do I need, where the fuck does it all begin.

Right now it’s a stage of thinking, which will later flow into tests.
According to budgets, I hope not to cost more than 25k rubles.
the price for delivering sensors to Russia is just fucking fucked up (60++ euros per bag, fucking trade unions and sanctions)

In terms of software, at first I thought this was the top: peppapighs/libhmk, because this is the best open source software for analog keyboards that can be found so far. It’s a pity that no one has messed with the TMR section yet, but overall I don’t think there’s a big difference. (more on the difference later)

But unfortunately author stated - there will be no support for split
And implementing such a theme on your own is fucking hell, which will probably require re-wiring all the software. Because there is no implementation of communication and synchronization of two controllers (such as uart/i2c/spi) Well, at least you can put some kind of wireless on top of tinyusb if you break your ass a little.

But in order not to tear my ass, I’ll rather look towards zmk because This is one of the best solutions for keyboard firewood.
And some idiot is already making a module for it to support HE boards, with a rapid trigger, socd and other cool features.

So we raised the topic of software…

But there is no mention of TRM anywhere.
But no one has ever made keyboards on TMR in the open source.
Moreover, no one has made Split Wireless TMR keyboards.

Everywhere current HE-HE-HE

This is one of the key problems of this project - there are no examples.
But fortunately there is already some progress in the HE field.
And there is hope that there will be no special problems with TMR.

Let’s move on to the difference between TMR and HE.

Pachama, I have hope that I can push TMR sensors under HE firewood without tearing my ass?

• TMR and HE have the same pinout (if we consider keyboard-friendly options in the SOT23-3 case)

GND, Vcc, Out

• Can operate in the same voltage range

Keyboards usually dance at 3.3v - both technologies can work in this field

• Similar transfer function

HE: VOUT = VQ + S*B
TMR: VOUT = VCC*(VOFFSET + S*B)

, where
VOUT - output voltage
VCC - supply voltage
VOFFSET - offset
VQ - Voltage at B = 0
S - sensitivity
B - induction (don’t give a fuck, the position of the magnet, the switch is tightly clamped)

In short, it’s just bullshit, we just need to take Vcc into account, which may become a problem in the future.

The theme itself will be a columar format, like on a keyboard (it has a little more - 64 buttons, I think this keyboard will still have 58-60 buttons), which few people will be interested in.
But questions about HE/TMR are common, regardless of the layout, I hope at least someone will be interested in reading some of my belongings and research on this topic…

A.K.A.

Долгий путь к мечте

Если кратко…

У меня уже давно есть желание собрать кастомную клавиатуру с нуля…
Ета писанина по-сути своей является моим шитпостом (хз нахуя::я люблю писать буковы)
Буду сюда вываливать свои мысли по поводу сего проектица, если ето можно так назвать. (вроде работы овердохуя, наверна можно)

Чотамкак

Известно, что на рынке клавиатур последние несколько лет попсует тема с аналоговыми клавиатурами, в основном на базе Hall-Effect сенсоров
Плюшки перечислять не вижу смысла, они очевидны.
А из минусов - ебейшее энергопотребление HE клавиатур по сравнению с механикой.
Что значительно усложняет сборку беспроводной клавы…

Для многих может показаться что беспровод - бесполезное говно, нахуй никому ненужное.
Я до каких то пор сама так думала, сидя на стаггеред 2кг куске аллюминия с кнопками.
Но потом в моих руках оказалась split клавиатура без единого провода.
: включил 2 половинки, пихнул usb донгл в комп и работаешь
держит заряд месяца 3 при 15 часовом ежедневном юзе с 1500мач аккумами в каждой половинке (механика хуле)
И эт оказалось настолько удобно, что я больше не мыслю клавиатуру, в которой будут провода.

Потому я гляжу в сторону tmr, ибо хавает он раз так в 8 меньше, чем he
Хотя с ним должно быть есть подводные камни в виде нестабильного Vcc, что может гадить их ебанутую в сравнении с he точность (ну вапще на самом деле они тупа меньше шумят, по точности не прям ебут)

Собсна чо мне нада, с чего нахуй всё начинается.

Щас пока этап кумеканья, который позже перетечет в тесты.
По бюджетам я надеюсь не уйти дороже 25к руб.
цена доставки сенсоров в россию это пиздец просто нахуй (60++ евро за пакетик ебанные профсоюзы и санкции)

По софту - я сначал показалось, что это топ: peppapighs/libhmk, ибо это лучший опенсурс софт для аналоговых клав, чо пока можно найти. Жаль на нём пока вроде никто не мутил TMR поделия, но в целом не думаю, что велика разница. (о разнице позже)

Но к сожалению якы заявил аффтор - поддержки split не буде
А имплементить такую тему самостоятельно - ебанутый ад, который потребует, должно быть, перековырчивания всего софта. Т.к. там нет реализации связи и синхронизации двух контроллеров (типа uart/i2c/spi) Ну хотяб беспровод какой-то налопатить поверх tinyusb можно если немного порвать жопу.

Но дабы не рвать жопу, скорее буду глядеть в сторону zmk т.к. это одино из лучших решений для дров клавы.
И на него уже какой-то пиздузиаст пилит модуль для поддержки HE бордов, с раппид триггером, socd и прочими крутыми фичами.

Вот мы подняли тему софта…

А ведь нигде нет упоминаний TRM.
А ведь никто и не делал в опенсурсе клавы на TMR.
А ведь тем более никто не делал Split Wireless TMR клавы.

Везде тока HE-HE-HE

Это одна из ключевых проблем этого проекта - нет примеров.
Но благо уже есть какие-то подвижки на HE поле.
И есть надежда что с TMR не будет особых проблем.

Перейдём собсна к разнице TMR и HE.

Пачаму у меня есть надежда, что я смогу пихнуть TMR датчики, под HE дрова, при этом не порвав жопу?

• TMR и HE имеют одинаковую распиновку (если рассматривать удобные для клавы варианты в SOT23-3 корпусе)

GND, Vcc, Out

• Могут работать в одном и том же диапазоне напряги

Клавы обычно пляшут от 3.3v - обе технологии могут работать на этом поле

• Схожая передаточная функция

HE: VOUT = VQ + S*B
TMR: VOUT = VCC*(VOFFSET + S*B)

, где
VOUT — выходное напряжение
VCC — напряжение питания
VOFFSET — смещение
VQ - Напряга при B = 0
S — чувствительносты
B — индукция (похуй, положение магнита, наскильно сильно зажат свитч)

Кароче одна хуйня, нам нада только учитывать Vcc, что может станет проблемой в будущем.

Сама темка будет columar формата, типа как на кортинке (на ней чутьб больше - 64 кнопки, я думаю в этой клаве таки будет 58-60 кнопок), что мало кому интересно.
Но вопросецы по поводу HE/TMR общие, независимо от лейаута, надеюсь хоть комута будет интересно почитать какие-та мои пожитки и исследования в этой теме…

Proper docs in English: github/scclie/sccl_nix/README.md

am just dumping thoughts here

Why the fuck Why?

In the past, after 6 years of Arch-only use - I didn’t get it either.

Like, here’s yet another trendy distro, something like Fedora, Manjaro and other cuties.

Then I felt like installing it…

After that, apparently, my world flipped upside down.

A bunch of problems that plagued regular distros - solved instantly. I didn’t even realize they were problems before - after years of using standard distros you reach a consensus, you just get used to how you’re supposed to work in them for things to be chill.

But one kind of chill and another kind of chill - those are two completely different kinds of chill.

The funniest part - problems you don’t even think of as problems. Configs scatter across /etc, packages get installed and forgotten, systemd units are enabled by hand and lost. Six months later the system is a black box. You have no idea how it got to this state.

Fucking git for /etc? fr

NixOS offers the opposite: you describe the end result. All packages, configs, users, services - one build, one state.

Want a second machine? Same config, different host. Want to roll back? Slam the previous generation. Every build lives in /nix/store, nothing gets scattered across /usr and /etc randomly.

A separate joy with shells. You often need “disposable programs” - install, use, forget. And it’s sitting in the system ;k

Nix offers nix shell - throw in any programs, use them, forget - they get cleaned up on garbage collection. Dependencies are only pulled into your shell from /nix/store.

You can just nix run nixpkgs#imagemagick -- convert ... and it downloads, runs, and disappears on the next garbage collector run. Zero traces.

manually, if you wanna clean up - you slam nix-collect-garbage -d.

Where Nix even came from

In 2006, a cool dude named Eelco Dolstra defended his PhD at Utrecht University. Thesis topic: “The Purely Functional Software Deployment Model”

The idea was radical: what if a package is a pure function?

Input: source + dependencies + compile flags. Output: binary.

Same input = same output. Always. On any machine. None of that “it builds on my machine”.

For this, /nix/store is arranged with genius simplicity. Each package lives in its own directory, and the path includes a hash of all inputs:

/nix/store/5mq2jcn36ldd97xrcnf3jg8irnfp5xqr-fish-4.0.1/

The hash depends on sources, dependencies, compile flags, compiler version. EVERYTHING.

Any change - different hash - different path. Two packages don’t conflict because they’re in different directories. Atomic updates. None of that “I installed the new version and broke the old one”.

It’s a completely different paradigm compared to other package managers.

The nixpkgs ecosystem is now the largest package repository in the world. All of it built by one Hydra farm and cached in a binary cache.

honestly, the numbers are a bit inflated - a lot of packages are split into tons of tiny ones. In terms of actual software, nixpkgs is smaller than e.g. AUR.

Imperative vs declarative

As was dumped out in some very old thought back at the dawn of Nix - package managers can be compared to programming languages.

There’s an article “Functional Package Management with Guix” where this idea is well explored, but it sounded earlier too.
too lazy to dig up where else, but it was.

Imperative package managers (apt, yum, pacman) - like procedural programming. You tell the system WHAT TO DO: apt install nginx, then systemctl enable nginx, then manually the config in /etc/nginx/nginx.conf. A sequence of commands mutates state.

Declarative ones (Nix, Guix) - like functional. You describe WHAT RESULT you want:

services.nginx = {
  enable = true;
  virtualHosts."example.com" = {
    root = "/var/www/example.com";
  };
};

Not “install nginx and configure it”. But “this is what nginx should be in the system”.

The difference is fundamental. In the imperative world you lose history - the system remembers the current state but not how it got there. In declarative - each build is a function of the config. Want to replicate on another machine? Same config, same result.

and what’s next? Some higher-level approach, more abstract? (or a mega-abstract llm-based chat interface??????? - ai problem resolver :D )

Ecosystem

NixOS by itself only solves part of the problem. The system level. But there’s a ton more you want to declarativize.

flakes

An experimental feature since 2021. Still experimental.

But in practice everyone’s been on flakes for ages. They solve two main problems of old Nix: dependency versioning (via flake.lock) and a unified project format.

Before flakes there was channels - global system state. Switch the channel - it changes for everything. Zero isolation.

With flakes, each project has its own flake.lock that pins specific versions of ALL dependencies. Like package-lock.json but for the entire system.

The flake auto-discovers hosts from directories - drop hosts/<hostname>/, it picks it up as nixosConfigurations.<hostname>. No if hostname == hacks at the discovery level.

home-manager

10k stars on GitHub. Lets you declaratively manage your user environment - dotfiles, user packages, services.

Previously dotfiles were managed with GNU stow or bare git repos. home-manager lets you do the same thing but Nix-style: with options, dependencies, immutability.

And the main thing - integrates as a NixOS module. One nixos-rebuild switch rebuilds both the system and the user environment.

disko

NixOS is a distro where everything is described as code. Except one thing: disk partitioning during installation is done manually. disko fixes this sad omission.

You write the disk config once instead of messing with gparted every time.
If hosts have identical disks - you can replicate freely.

sops-nix

Secrets (SSH keys, passwords, GPG) are encrypted with an age key and live right in the repo. At build time they’re decrypted into the right places.

Previously secrets were either kept outside the repo (and lost), or in encrypted git repos (inconvenient). sops-nix makes it transparent: secrets as part of the config, but encrypted.

The scaling problem

There’s one catch with NixOS. You start with one host, everything’s beautiful. Then you add a second. Then a third.

And the config turns into a dump of exceptions and such. (just like any codebase)

There are other approaches:

• flake-parts - a modular system for flakes, lets you split config into reusable modules. Good for large projects but adds its own abstraction layer.
• snowfall-lib - a library for organizing Nix configs with auto-discovery. Similar to what I do, but with its own philosophy.
• Tons of people just live with if hostname and don’t sweat it. Also an option if you have 1-2 hosts.

And that’s where sccl_nix was born - my configuration that tries not to turn into a dump. (turned into one a couple times, but I try really hard)
I wanted an architecture where adding a new host means creating a folder and declaring sccl.* options. Without a single if.

sccl_nix architecture

Dotfiles are split into three entities.

hosts - hardware and system stuff. Disks (disko), GPU drivers, network, system packages. Anything that can’t be synced between different machines. Auto-discovered by the flake from hosts/.

profiles - a user with their zoo of programs, shell and user-level junk. One host can have any number of profiles. Imported into the host config.

shared - base for everyone. Fish, niri, alacritty, waybar, basic CLI tools. Configure once - import into all profiles.

Currently two hosts: sacculos (desktop, AMD) and aero15laptop (laptop, NVIDIA). Two profiles: paper (main, with the whole zoo) and bootstrap (minimal, just vim, nmtui and ssh for USB installs).
as an example of real usage.

Diagram:

flowchart TD
    F["❄️ flake.nix<br/>auto-discovery: hosts + shells"]

    NM["⚙️ nixos/modules/core.nix<br/>sccl.* options: conditional config"]

    H1["🖥️ hosts/sacculos<br/>desktop + amd gpu"]
    H2["💻 hosts/aero15laptop<br/>laptop + nvidia gpu"]

    P1["👤 profiles/paper<br/>main: steam, blender..."]
    PS["📦 profiles/shared<br/>base: fish, niri, waybar..."]

    PB["🪶 profiles/bootstrap<br/>minimal: nmtui, vim, ssh"]

    S["🔐 secrets/ sops-nix encrypted"]
    SH["🐚 shells/ auto-discovered devShells"]

    F --> H1
    F --> H2
    F --> SH

    H1 --> NM
    H2 --> NM

    H1 --> P1
    H2 --> P1

    H1 --> PB
    H2 --> PB

    P1 --> PS

    classDef flakeStyle stroke:#517599,stroke-width:2px,color:currentColor
    classDef hostStyle stroke:#5e81ac,stroke-width:2px,color:currentColor
    classDef profileStyle stroke:#8fbcbb,stroke-width:2px,color:currentColor
    classDef sharedStyle stroke:#d08770,stroke-width:2px,color:currentColor
    classDef moduleStyle stroke:#bf616a,stroke-width:2px,color:currentColor
    classDef secretStyle stroke:#bf616a,stroke-width:2px,color:currentColor
    classDef shellStyle stroke:#d08770,stroke-width:2px,color:currentColor

    class F flakeStyle
    class H1,H2 hostStyle
    class P1,PB profileStyle
    class PS sharedStyle
    class NM moduleStyle
    class S secretStyle
    class SH shellStyle

sccl.*

The main feature that keeps the config from sliding into if hostname == hell.

In core.nix ALL options are defined, and they all default to false. Each module gates itself via lib.mkIf config.sccl.<feature>.enable.

{ config, lib, ... }:
{
  config = lib.mkIf config.sccl.zapret.enable {
    services.zapret = { ... };
  };
}

None of that if hostName == "laptop" then false. The module simply doesn’t turn on.

Full option list (at the time of writing, idk if I’ll update it):

sccl.ui.enable           # Nord theme + greetd
sccl.audio.enable        # pipewire
sccl.bluetooth.enable    # bluetooth + blueman
sccl.net.enable          # networkmanager + proxy + firewall
sccl.automount.enable    # udisks2 USB automount
sccl.secrets.enable      # sops-nix encrypted secrets
sccl.zapret.enable       # DPI bypass
sccl.flclashx.enable     # FlClashX proxy GUI
sccl.playground.enable   # Docker + dev tools
sccl.chaotic.enable      # chaotic-nyx repo
sccl.nix-ld.enable       # nix-ld for non-nixpkgs binaries
sccl.bootstrap           # bool: minimal install mode

A host config literally looks like this:

sccl = {
  ui.enable = true;
  audio.enable = true;
  net.enable = true;
  automount.enable = true;    # desktop only
  zapret.enable = true;       # desktop only
  playground.enable = true;   # desktop only
  nix-ld.enable = true;
};

Adding a new host - copy the folder, tweak configuration.nix, generate hardware-configuration.nix, tweak disko.nix. The flake picks it up automatically.

The bootstrap profile solves the problem of installing on weak hardware. Deploy bootstrap (~1-2 GB), boot up, flip sccl.bootstrap = false, rebuild - and you have a full system. No need to wait for 100500 packages to compile from a USB stick that barely has space.

You can use nixos-anywhere for this, but bootstrap stays as a backup option.

Keyboard and secrets

Layout

The keyboard layout is parametrized through flake arguments (specialArgs).

sacculos has an ergo-split on Vial firmware - us,rulemak_vial. aero15laptop is colemak_dh,rulemak. One mkHost in flake.nix, and all layers (system keyboard, XKB, WM) get the right layout.

At the WM level (niri) the layout is also passed as a parameter: Colemak-CAWS on the desktop, Colemak-DH-Wide on the laptop. This is nice when you have different keyboards with different firmware and different layouts on different machines.

No copypaste, no hacks.

Secrets

SSH keys, GPG - everything is encrypted via sops-nix with an age key and lives right in the repo at secrets/common.yaml.

On rebuild with sccl.secrets.enable = true, keys decrypt into ~/.ssh/, GPG imports automatically.

The only thing to keep separately - the private age key. It lives in my password manager, not in the repo.

The catch?

I’ve got a few.

Nix is a different language. Not just config syntax, but a full functional language. Lazy, dynamically typed, with its own weird standard library. The learning curve is a sheer wall.

Documentation. It exists, but… You learn a lot by trial and error and reading other people’s configs. How to Learn Nix by Ian Henry is literally a 50+ post diary of a guy learning Nix.

Build time. The first build can take a while, especially if little is cached. But Hydra caches almost everything, so subsequent builds are fast.

Flakes experimental since 2021. Still. But everyone uses them. The status is more of a formality at this point.

Overkill for simple things. If you have one server with nginx - you don’t need NixOS. But if you have 3+ machines, custom kernel patches, your own software built from git - it’s worth it.

Overall: yeah, with enough skill you can still make a mess. But the sccl_nix architecture at least tries to prevent it. I believe in it (trying to)

so far so good. desktop and laptop live on the same config with the same profile. I always get the same working environment and don’t even notice whether I’m on the laptop or PC (my posture notices) - everything is always configured identically.

Нормальная дока на ангельском: github/scclie/sccl_nix/README.md

тут я просто вываливаю мысли

На*&я Зачем?

Вот мне раньше, после 6 лет юза онли арча - тоже не было понятно.

Мол наплодили ещё какой-то попсовый дистр, аля федоры, манжары и прочих качи.

А потом мне захотелось его установить…

После этого, видимо, мир перевернулся.

Куча проблем, что возникали на обычных дистрах - решились моментами. Мне даже ранее не казалось что это проблемы - за годы использования стандартных дистров ловишь консенсус, просто привыкаешь к тому как над в них работать, чтоб всё было заебись.

Но то заебись и это заебись - это совершенно два разных заебись.

Самое смешное - проблемы, о которых даже не думаешь как о проблемах. Конфиги расползаются по /etc, пакеты ставятся и забываются, systemd-юниты включаются ручками и теряются. Через полгода система - чёрный ящик. Ты понятия не имеешь, как она дошла до жизни такой.

Хуярить ебучий git для /etc? fr

NixOS предлагает обратное: ты описываешь конечный результат. Все пакеты, конфиги, юзеры, сервисы - один билд, одно состояние.

Хочешь вторую машину? Те же конфиги, другой хост. Хочешь откатиться? Въёбываешь предыдущую генерацию. Каждый билд лежит в /nix/store, ничего не раскидывается по /usr и /etc как попало.

Отдельный кайф с шеллами. Часто надо поставить “одноразовые проги” - поставил, юзанул, забыл. А оно лежит в системе ;k

Никс предлагает nix shell - накидал любых прог, поюзал, забыл - само удалится при сборке мусора. Зависимости тянутся только в твой шелл из /nix/store.

Можно просто nix run nixpkgs#imagemagick -- convert ... и оно скачается, исполнится, и при следующем garbage collector исчезнет. Никаких следов.

ручками, если хочш почистить - nix-collect-garbage -d втуливаешь.

Откуда вообще Nix

В 2006 году крутой мужик по имени Eelco Dolstra защитил PhD в Utrecht University. Тема диссертации: “The Purely Functional Software Deployment Model”

Идея была радикальной: а что если пакет - это чистая функция?

Вход: исходники + зависимости + флаги компиляции. Выход: бинарник.

Одинаковый вход = одинаковый выход. Всегда. На любой машине. Без “у меня собирается а у тебя нет”.

Для этого /nix/store устроен гениально просто. Каждый пакет лежит в своей директории, и путь включает хеш всех входных данных:

/nix/store/5mq2jcn36ldd97xrcnf3jg8irnfp5xqr-fish-4.0.1/

Хеш зависит от исходников, зависимостей, флагов компиляции, версии компилятора. ВСЕГО.

Любое изменение - другой хеш - другой путь. Два пакета не конфликтуют потому что лежат в разных директориях. Атомарные обновления. Никакого “я поставил новую версию и поломал старую”.

Эт совершенно другая парадигма, по сравнению с другими пакетниками.

Экосистема nixpkgs сейчас - крупнейший в мире репозиторий пакетов. И всё это собирается одной фермой Hydra и кешируется в бинарный кеш.

на самом деле немного обман цифр - очень много пакетов разбиты на куча маленьких. Если смотреть по реальному софту - nixpkgs меньше чем тот же aur.

Императивное vs декларативное

Как вываливали в какой-то очень старой мысли ещё на заре придумывания Nix - пакетники можно сравнить с языками программирования.

Есть статья “Functional Package Management with Guix” где эта мысль хорошо раскрыта, но идея звучала и раньше.
мне лень искать, где ещё, но было.

Императивные пакетники (apt, yum, pacman) - это как процедурное программирование. Ты говоришь системе ЧТО ДЕЛАТЬ: apt install nginx, потом systemctl enable nginx, потом ручками конфиг в /etc/nginx/nginx.conf. Последовательность команд меняет состояние.

Декларативные (Nix, Guix) - это как функциональное. Ты описываешь КАКОЙ РЕЗУЛЬТАТ нужен:

services.nginx = {
  enable = true;
  virtualHosts."example.com" = {
    root = "/var/www/example.com";
  };
};

Не “поставь nginx и настрой”. А “вот такой nginx должен быть в системе”.

Разница фундаментальная. В императивном мире ты теряешь историю - система помнит текущее состояние, но не помнит как она в него пришла. В декларативном - каждый билд это функция от конфига. Хочешь повторить на другой машине - тот же конфиг, тот же результат.

а дальше чо? Какой-то более высокоуровневый подход, более абстрактный? (иль мега абстрактный llm-based chat interface??????? - ai problem resolver :D )

Экосистема

Сам по себе NixOS решает только часть проблемы. Системный уровень. А есть ещё куча всего, что хочется в декларативщину.

flakes

Экспериментальная фича с 2021 года. До сих пор экспериментальная.

Но по факту все давно сидят на флейках. Они решают две главные проблемы старого Nix: версионирование зависимостей (через flake.lock) и единый формат проекта.

До флейков был channels - глобальное состояние системы. Поменял канал - поменялось для всего. Никакой изоляции.

С флейками у каждого проекта свой flake.lock, который фиксирует конкретные версии ВСЕХ зависимостей. Как package-lock.json но для всей системы.

Флейк авто-дискаверит хосты из папок - кидаешь hosts/<hostname>/, он сам подхватывает в nixosConfigurations.<hostname>. Никаких if hostname == костылей на уровне дискаверинга.

home-manager

10k звёзд на гитхабе. Позволяет декларативно управлять пользовательским окружением - дотфайлы, пользовательские пакеты, сервисы.

Раньше дотфайлы делали через GNU stow или bare git repo. home-manager позволяет всё то же самое, но в Nix-стиле: с опциями, с зависимостями, с иммутабельностью.

И главное - интегрируется с NixOS модулем. Один nixos-rebuild switch пересобирает и систему и пользовательское окружение.

disko

NixOS - это дистр где всё описывается как код. Кроме одного: разметка дисков при установке делается ручками. disko исправляет это печальное упущение.

Достаточно один раз прописать конфиг разметки дисков, а не дрочить каждый раз gparted
Если хосты с одинаковыми дисками - можно спокойно реплиецировать.

sops-nix

Секреты (SSH-ключи, пароли, GPG) шифруются age-ключом и лежат прямо в репе. При билде расшифровываются в нужные места.

Раньше секреты хранили либо вне репы (и теряли), либо в зашифрованных git-репо (неудобно). sops-nix делает это прозрачно: секреты как часть конфига, но зашифрованы.

Проблема масштабирования

С NixOS есть одна засада. Ты начинаешь с одного хоста, всё красиво. Потом добавляешь второй. Потом третий.

И конфиг превращается в свалку из кучи исключений и т.п. (всё как в любом коде)

Есть и другие подходы:

• flake-parts - модульная система для флейков, позволяет разбивать конфиг на переиспользуемые модули. Хорош для больших проектов, но добавляет свой слой абстракции.
• snowfall-lib - библиотека для организации Nix-конфигов с авто-дискавери. Похожа на то что делаю я, но со своей философией.
• Куча народу просто живёт с if hostname и не парится. Тоже варик, если хостов 1-2.

Собственно, из этого и родился sccl_nix. - моя конфигурация, которая пытается не превратиться в помойку. (пару раз превращалась, но я очень стараюсь)
Мне хотелось архитектуру, где добавление нового хоста - это создание папки и декларирование sccl.* опций. Без единого if.

Архитектура sccl_nix

Дотфайлы разделены на три сущности.

hosts - железо и системщина. Диски (disko), дрова GPU, сеть, системные пакеты. Всё что нельзя синкать между разными машинами. Авто-дискаверятся флейком из hosts/.

profiles - пользователь со своим зоопарком прог, шеллом и user-level хламом. На одном хосте может быть сколько угодно профилей. Импортятся в конфиг хоста.

shared - база для всех. Рыба, niri, alacritty, waybar, базовые CLI тулзы. Один раз настроил - импортнул во все профили.

Сейчас два хоста: sacculos (десктоп, AMD) и aero15laptop (ноут, NVIDIA). Два профиля: paper (основной, со всем зоопарком) и bootstrap (минимальный, только vim, nmtui и ssh для установки с флешки).
как пример реального юза.

Схема:

flowchart TD
    F["❄️ flake.nix<br/>auto-discovery: hosts + shells"]

    NM["⚙️ nixos/modules/core.nix<br/>sccl.* options: conditional config"]

    H1["🖥️ hosts/sacculos<br/>desktop + amd gpu"]
    H2["💻 hosts/aero15laptop<br/>laptop + nvidia gpu"]

    P1["👤 profiles/paper<br/>main: steam, blender..."]
    PS["📦 profiles/shared<br/>base: fish, niri, waybar..."]

    PB["🪶 profiles/bootstrap<br/>minimal: nmtui, vim, ssh"]

    S["🔐 secrets/ sops-nix encrypted"]
    SH["🐚 shells/ auto-discovered devShells"]

    F --> H1
    F --> H2
    F --> SH

    H1 --> NM
    H2 --> NM

    H1 --> P1
    H2 --> P1

    H1 --> PB
    H2 --> PB

    P1 --> PS

    classDef flakeStyle stroke:#517599,stroke-width:2px,color:currentColor
    classDef hostStyle stroke:#5e81ac,stroke-width:2px,color:currentColor
    classDef profileStyle stroke:#8fbcbb,stroke-width:2px,color:currentColor
    classDef sharedStyle stroke:#d08770,stroke-width:2px,color:currentColor
    classDef moduleStyle stroke:#bf616a,stroke-width:2px,color:currentColor
    classDef secretStyle stroke:#bf616a,stroke-width:2px,color:currentColor
    classDef shellStyle stroke:#d08770,stroke-width:2px,color:currentColor

    class F flakeStyle
    class H1,H2 hostStyle
    class P1,PB profileStyle
    class PS sharedStyle
    class NM moduleStyle
    class S secretStyle
    class SH shellStyle

sccl.*

Главная фича, которая не даёт конфигу скатиться в свалку if hostname ==.

В core.nix определены ВСЕ опции, и все они по дефолту false. Каждый модуль гейтит сам себя через lib.mkIf config.sccl.<feature>.enable.

{ config, lib, ... }:
{
  config = lib.mkIf config.sccl.zapret.enable {
    services.zapret = { ... };
  };
}

Никаких if hostName == "laptop" then false. Модуль просто не включается.

Полный список опций (на момент написания статьи, хз буду ли обновлять):

sccl.ui.enable           # Nord-тема + greetd
sccl.audio.enable        # pipewire
sccl.bluetooth.enable    # bluetooth + blueman
sccl.net.enable          # networkmanager + прокси + firewall
sccl.automount.enable    # udisks2 автоподключение флешек
sccl.secrets.enable      # sops-nix шифрованные секреты
sccl.zapret.enable       # обход DPI
sccl.flclashx.enable     # FlClashX GUI для прокси
sccl.playground.enable   # Docker + dev tools
sccl.chaotic.enable      # chaotic-nyx репо
sccl.nix-ld.enable       # nix-ld для бинарников не из nixpkgs
sccl.bootstrap           # bool: минимальный режим установки

Конфиг хоста выглядит буквально так:

sccl = {
  ui.enable = true;
  audio.enable = true;
  net.enable = true;
  automount.enable = true;    # только на десктопе
  zapret.enable = true;       # только на десктопе
  playground.enable = true;   # только на десктопе
  nix-ld.enable = true;
};

Добавление нового хоста - скопировал папку, поправил configuration.nix, сгенерил hardware-configuration.nix, поправил disko.nix. Флейк сам его подхватит.

Bootstrap-профиль решает проблему установки на слабом железе. Накатил bootstrap (~1-2 GB), загрузился, переключил sccl.bootstrap = false, перебилдил - и вот полная система. Не надо ждать пока на ноуте соберётся 100500 пакетов с флешки где ещё и места нет.

Для этого можно юзать nixos-anywhere, но bootstrap остаётся как бекап-вариант.

Клава и секреты

Раскладка

Раскладка параметризована через аргументы флейка (specialArgs).

У sacculos эрго-сплит на Vial прошивке - us,rulemak_vial. У aero15laptop - colemak_dh,rulemak. Один mkHost в flake.nix, и все слои (системная клава, XKB, WM) получают правильную раскладку.

На уровне WM (niri) раскладка тоже передаётся параметром: на десктопе Colemak-CAWS, на ноуте Colemak-DH-Wide. Это удобно когда у тебя разные клавиатуры с разной прошивкой и разными раскладками на разных машинах.

Без копипасты и костылей.

Секреты

SSH-ключи, GPG - всё зашифровано через sops-nix с age-ключом и лежит прямо в репе в secrets/common.yaml.

При ребилде с sccl.secrets.enable = true ключи сами расшифровываются в ~/.ssh/, GPG импортится автоматом.

Всё что над хранить отдельно - приватный age-ключ. Он у меня в менеджере паролей, не в репе.

Подвох?

Их есть у меня.

Nix - это другой язык. Не просто синтаксис конфигов, а полноценный функциональный язык. Ленивый, с динамической типизацией, со своей странной стандартной библиотекой. Кривая обучения - отвесная стена.

Документация. Она есть, но… Многое узнаёшь методом тыка и чтения чужих конфигов. How to Learn Nix от Ian Henry - это буквально дневник на 50+ постов о том как чувак учил Nix.

Время билда. Первый билд может идти долго, особенно если мало что закешировано. НоHydra кеширует почти всё, т.ч. последующие билды быстрые.

Flakes experimental с 2021. До сих пор. Но все используют. Статус скорее формальность на этом этапе.

Оверкилл для простых вещей. Если у тебя один сервер с nginx - тебе не нужен NixOS. Но если у тебя 3+ машины, кастомные патчи ядра, свой софт собранный из git - оно того стоит.

В целом: да, при большом скилле и тут можно насрать. Но архитектура sccl_nix хотя бы пытается этого не допустить. я в это верю (пытаюсь)

пока полёт нормальный. десктоп и ноут живут на одном конфиге с одинаковым профилем. Я получаю всегда одинаковую рабочую среду и даже не замечаю сижу ли я за ноутом, иль за пк (моя осанка замечает) - всё всегда настроено одинакого.

Visuomotor Feedback Loop

This entire phenomenon can be described by a single term - Visuomotor Feedback Loop. Essentially, this is an information processing cycle that the nervous system runs at maximum possible speed:

Loop stages:

1. Visual analysis. The eye captures the current position of the target and its trajectory. Assessment of distance, movement vector, movement speed.

2. Information processing. The brain processes visual data and calculates the necessary motor command. Micro-calculation occurs: distance, route prediction, turn angle calculation, etc.

3. Command execution. Muscles receive the signal and perform the movement. The mouse moves to the desired position.

4. Repeat. The loop closes and starts again.

Reactive tracking works precisely on the basis of this loop. This is a sequence of micro-corrections that occur at such speed that they appear as a single smooth action. Even pro players perform the same micro-corrections, but their interpolation (smoothing between cycles) reaches a level where the movement looks absolutely smooth - each micro-correction adds to the initial vector rather than being a new movement vector. Plus, an experienced system incorporates slight trajectory prediction, pre-calculating the target’s next position.

Novice vs Professional

Novice:

• Sees target → processes information slowly → movement calculation (often occurs incorrectly, with artifacts and unnecessary movements) → hand performs action → result analysis → waiting → next flick

Noticeable gaps appear between loop cycles. Each flick is perceived as a separate, discrete operation rather than part of a continuous flow.

Professional:

• Sees target → fast accurate information processing → micro-correction, even if the initial movement was inaccurate → instant result analysis → next correction

The professional’s loop spins faster. Unlike the novice, an experienced player is capable of qualitatively correcting their previous movements - for example, while previously moving in a straight line, they can add precise correction within the same movement vector such that it won’t look like a flick or shake. These micro-adjustments layer upon each other, creating the appearance of smooth, continuous tracking.

Skill Development Mechanism

Many hours of training in aim trainers allow for optimization of the speed and effectiveness of the visuomotor feedback loop. The system learns to:

• Analyze visual flow faster

• Analyze qualitatively - form more precise motor commands without unnecessary movements

Result: micro-corrections that previously were visible as distinct jerks begin to merge into a single smooth movement.

Conclusion

Shakiness and jerks (flickshots with noticeable intervals) are signs of insufficient speed and accuracy of information processing. The system simply doesn’t manage to perform the necessary number of micro-corrections and has to make macro-movements.

Smooth tracking is the result of high speed and loop efficiency. Micro-corrections occur so frequently that they become practically invisible.

Tracking skill development is acceleration of the visuomotor feedback loop and optimization of its efficiency. Over time: better prediction, better interpolation, better synchronization, better analysis quality, artifacts disappear, etc.

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

Зрительно-моторная петля

Все это явление можно описать одним термином - Зрительно-моторная петля (visuomotor feedback loop). По сути, это цикл обработки информации, который нервная система прогоняет на максимально возможной скорости:

Этапы петли:

1. Визуальный анализ. Глаз фиксирует текущее положение цели и ее траекторию. Оценка дистанции, вектора движения, скорости перемещения.

2. Обработка информации. Мозг обрабатывает визуальные данные и рассчитывает необходимую моторную команду. Происходит микро-калькуляция: дистанция, предугадание маршрута, расчет угла поворота и т.п.

3. Исполнение команды. Мышцы получают сигнал и совершают движение. Мышь перемещается в нужную позицию.

4. Повтор. Петля замыкается и начинается заново.

Реактивный трекинг работает именно на основе этой петли. Этопоследовательность микро-коррекций, которые происходят с такой скоростью, что кажутся единым плавным действием. Даже про-игроки совершают те же микро-коррекции, только их интерполяция (сглаживание между циклами) достигает уровня, при котором движение выглядит абсолютно гладким, каждая микро коррекция плюсуется к инишиал вектору, а не является новым вектором движения. Плюс опытная система закладывает небольшое предугадание траектории, допредсказывая следующую позицию цели.

Новичок vs Профессионал

Новичок:

• Видит таргет → долго обрабатывает информацию → расчет движения (часто происходит некорректно, с артефактами, лишними движениями) → рука совершает действие → анализ результата → ожидание → следующий флик

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

Профессионал:

• Видит таргет → быстрая точная обработка информации → микро-коррекция, даже если первоначальное движение было неточным → мгновенный анализ результата → следующая коррекция

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

Механизм развития навыка

Многочасовая тренировка в аим-тренерах позволяет оптимизировать скорости и эффективность зрительно-моторной петли. Система обучается:

• Анализировать визуальный поток быстрее

• Качественно анализировать - формировать более точные моторные команды, без лишних движений

Результат: микро-коррекции, которые раньше были видны как отчетливые рывки, начинают сливаться в единое гладкое движение.

Итог

Тряска и рывки (flickshot с заметными интервалами) - это признак недостаточной скорости и точности обработки информации. Система просто не успевает совершить необходимое количество микро-коррекций, и приходится делать макро-движения.

Плавный трекинг - это результат высокой скорости и эффективности петли. Микро-коррекции происходят столь часто, что становятся практически незаметны.

Развитие навыка трекинга - это ускорение зрительно-моторной петли и оптимизация ее эффективности. Со временем лучше прогнозирование, лучше интерполяция, лучше синхронизация, лучше качество анализа, пропадают артефакты и т.п.

1. Surface Texture

• Abrasive / Medium Abrasive / Smooth
• Sandpaper-like or not
• How it interacts with skin and clothing sleeves
  

2. Friction Properties

Dynamic Friction (Glide):

• Resistance when the mouse is already in motion
• The lower it is, the easier the mouse glides after the initial movement
  

Static Friction (Stopping Power):

• Resistance at the moment you start moving the mouse
• The higher it is, the easier it is to stop the mouse precisely, but the harder it is to initiate movement
  

3. Glide Characteristics

• Mudpad Effect: High static + low dynamic friction == the mouse feels stuck at the start but glides smoothly afterward
• Consistent Glide: Minimal difference between static and dynamic friction
  

4. Speed Rating (Conventional)

• Control: High static and dynamic resistance, often a “mudpad,” but not always; the meta is often defined by static friction.
• Mid (Balanced): Moderate static and dynamic resistance, suitable for everything.
• Speed: Low resistance, heavy on tracking.
  You can play any game on any pad with enough skill and dedication; it’s primarily a question of average comfort.

5. X/Y Axis Consistency

• Is there a difference between left-right and up-down movement?
• Ideally, the X/Y ratio should be 1:1.

6. Durability & Maintenance

Moisture Resistance:

• A water absorption test usually indicates how quickly the pad will get dirty in general.
  

How to clean?

• Some pads are picky about the choice of cleaning products.
  

7. Base Construction

Firmness Level:

• X-Soft: Significant squish, can be pressed down almost to the desk.
• Soft: Noticeable, springy give.
• Mid: Firm support, almost no compression.
  

8. Surface Composition

• Weave type (Tight, Jacquard, Hybrid, Cordura, Textured)
• Material quality and stitching quality on the edges
• Base material and how well it grips the desk
  

9. Comparative Analysis

• Comparison with other popular models (Artisan, LGG, MGG, X-Raypad)
• Similarities in:
  • Speed and glide characteristics
  • Texture and tactile feel
  • Overall user experience
• Example: “Similar to the Artisan Raiden, but a bit slower” or “Feels like the G-SR-SE, but not as muddy”

Additional Tips:

1. Test with different mouse skates for a complete picture.

• It might be the case that:
• Skates A are faster on Pad X and slower on Pad Y.
• Skates B are faster on Pad Y and slower on Pad X.

2. How the glide changes over time. Some pads break in after a week and feel different.
3. What it’s best suited for (Arena shooters or tactical/angle-holding games. Better for Tracking, Switching, Click-timing, or Universal).

Good Example

9Sanya’s Spreadsheet

Типсы на грамотное объяснение характеристик коврика для мыши:

1. Текстура поверхности

• Абразивная / Средняя абразивная / Гладкая
• Наждак/не наждак
• Дружит ли с кожей и рукавом
  

2. Силы трения

Динамическое трение (скольжение):

• Сопротивление, когда мышь уже в движении
• Чем ниже — тем проще она несется после старта
  

Статическое трение (остановка):

• Сопротивление в момент, начала движения мышью
• Чем выше — тем проще стоппить мышь, но сложнее стартовать
  

3. Характер скольжения

• Эффект болота: Высокое статическое + низкое динамическое трение == мышь вязнет на старте, но потом неплохо скользит
• Ровное скольжение: Минимальная разница между статикой и динамикой
  

4. Скоростной рейтинг (условный)

• Контрольный (Control): Высокое статик и динамик сопротивление, зачастую болото, но не всегда, мета статики
• Средний (Mid): Умеренное статик и динамик сопротивление, подходит для всего
• Быстрый (Speed): Низкое сопротивление, трекинг хеви
  на любом ковре при желеании и достаточной скиллухе можно играть что угодно, вопрос удобства в среднем

5. Равенство по осям X/Y

• Есть ли разница между движением влево-вправо и вверх-вниз
• В идеале соотношение X/Y

6. Живучесть

Сопротивление влаге:

• Тест на впитываемость влаги обычно отражает насколько быстро ковёр в целом будет загрязняться
  

Чем мыть?

• Некоторые ковры придирчивы к выбору средств для мытья
  

7. Подложка (база)

Жесткость:

• XSoft: Сильно проминается, можно вдавить чуть ли не до стола
• Soft: Чувствуется упругая податливость
• Mid: Твердая поддержка, почти не прогибается
  

8. Состав поверхности

• Тип плетения (плотное, жаккард, гибридное, кордура, рельефное)
• Качество материала и прошивки краёв
• Материал основы и насколько хорошо она держится за стол
  

9. Сравнительный анализ

• Сравнениее с другими популярными моделями (Artisan, lgg, mgg, x-raypad)
• Сходства по:
  • Скорости и характеру скольжения
  • Тактильным ощущениям от текстуры
  • Общему впечатлению от использования
• Пример: “Похож на Artisan Raiden, но чуть меленее” или “Ощущения как от G-SR-SE, но не такой болотистый”

Доп Типсы:

1. Тест с разными глайдами на мышке для полной картины

• может быть такое что
• глайды A быстрее на коврике Х и медленее на коврике Y
• глайды B быстрее на коврике Y и медленее на коврике X

2. Характер глайда со временем, некоторые ковры через неделю приглаживаются и ощущаются иначе
3. Для чего он подходит больше всего (для ареновых шутеров или угловых. Лучше для трекинга, свитчинга, клинтинга или универсал)

Хороший пример

Таблица 9Sanya

In the world of cyber-athletes, hardcore gamers, and tryhards, the cult of aiming has been elevated to an absolute. Hours on training maps, endless duels, grinding in aim trainers, and the pursuit of the perfect sensitivity, mouse, mousepad, skates, posture, resolution, FOV, etc., etc. – these are the rituals of the modern neo-pilgrim, who believes that reaction speed and mouse precision will lead them to the top-1. But in reality, a hardcore analysis of most games “casualizes” aim as a key skill. In most modern competitive multiplayer games, “pure” aim is deliberately placed in a subordinate position by the developers. Its potential is harshly limited by systems designed to level the playing field between players of different skill levels.

The Great Equalizer: RNG, Movement, and Uncontrollable Factors

The main enemy of raw aiming skill is randomness and limitations. Developers figured out long ago that a game where victory belongs entirely to the one with faster reactions and better mouse control is doomed to a niche audience (the Quake series serves as an example). New players would leave, their asses sore, and matchmaking wouldn’t be able to handle the giant skill gap between the top and the bottom.

Hence, the crutch systems come into play:

• Random Bullet Spread (RNG Spread): The most obvious example. Even in the most popular tactical shooter Counter-Strike, which is considered the esports benchmark (well, at least it’s the most popular), bullets from any weapon while standing don’t fly strictly to one point, but within a certain circle of spread. In Valorant, this spread is even more pronounced. There’s no way to guaranteed control every bullet - you can only increase the probability of a hit. That’s a huge difference. Even a memorized spray pattern isn’t an exact science; it’s a ritual dance around random deviation.
  

• Movement Speed Control: A key but often overlooked aspect. In many games (CS2, Valorant, R6 Siege) the base movement speed of characters is relatively low and predictable. This is a powerful equalizing tool. Against a slow target, both a noob and a pro will aim almost equally effectively. The difference in their skill will be minimal. A tracking genius cannot reveal their full potential simply because the target doesn’t challenge them. The entire “spread” between bad and good aim shrinks. The difference becomes noticeable when a fast, unpredictable target appears. Here, a noob will simply get lost and won’t be able to hit it, while a cracked player, albeit with worse results than against a slow target, will still be able to track it. Thus, slow movement is a hidden mechanism that prevents a strong aimer from unleashing their full potential against a weak opponent.
  

• Moving Accuracy: A mechanic almost entirely removed from tactical shooters. In the same CS, firing while moving is synonymous with “miss.” This is a conscious decision that shifts the focus from shooting mechanics to positioning and tactics (counter-strafing, stop-shots).
  

• Bloom, damage falloff, complex ballistics - all these are layers of RNG that add a factor of luck to the equation. Sometimes a wild shot will hit, while a perfectly aimed one will miss.
  

The core idea is to lower the skill ceiling for aim (to neutralize the aim advantage). The difference between a good and a god-like aimer is negated by the fact that even a god can’t guarantee a hit due to RNG, and against a slow target, their superiority won’t be as noticeable. A novice always has a chance for a random hit or a “lucky” headshot.

High TTK vs Low TTK: The Aim-Dependency Paradox

Here lies the main paradox that many fail to grasp.

• Low TTK (Time To Kill): Characteristic of tactical shooters (CS2, Valorant, R6 Siege). A kill happens in 1-2 hits. It would seem that jewel-like aim is needed here to land headshots consistently. But in reality, aim is less important than it seems. The decisive factor is often not the pure shot, but: Positioning (you can catch an enemy by surprise, get an easy kill without even starting a duel), Angle knowledge (pre-fires, off-angles, etc.), Luck (a random bullet flew into the face. A noob just jerked their hand, fired while running/jumping and one-tapped a much stronger player).
  

• High TTK: A classic for arena shooters (Quake, Apex Legends, Overwatch 2, The Finals). Here, to kill an enemy, you need to continuously track them and hit them many times in a row. It’s simply impossible to track by accident for dozens of seconds.
  

And this is where raw aim takes the front seat. A lucky shot won’t decide anything here. You need to track the target long and accurately. In high-TTK games, the gap in aiming skill between players is much more visible. A strong player will consistently track and kill a novice, who simply won’t have the precision and mouse control to deal enough damage. Tactics and positioning alone won’t solve the problem here – you absolutely need to hit your shots (though you can try to compensate with movement, which again expands the aim-advantage spread based on the points above).

Escape from Aim: Tactics, Movement, and Abstract Abilities

Since pure aim is a difficult skill, requiring thousands of hours to hone, developers shift the focus to other, more “democratic” mechanics:

1. Tactics and Communication. You can be terrible with a mouse but still outsmart your opponent by taking unexpected positions, making calls for team play, and using utility.
   
2. Movement. In tactical shooters, it works as a limiter (slow and predictable). In arena shooters, it works as a divider (fast and complex), allowing a skilled player to dodge and demonstrate superior tracking.
   
3. Abilities. The most powerful tool for de-leveling aim. Why aim perfectly when you can spam your opponent with grenades, turrets, smokes, slow-fields, and flashbangs? These mechanics require not precision, but good decision-making and timing.
   

Conclusion

Aim undoubtedly remains an important skill. But most competitive games are designed to “casualize” it, to make it one of many factors for victory, but not the only one, and certainly not the primary (decisive) one. Slow movement, RNG spread, and an abundance of abilities are part of a design philosophy aimed at keeping the game accessible to millions, not just a select few with perfectly honed motor skills.

Not Memorization, but Adaptation

The main misconception is the idea of muscle memory as a rigid recording in the neurons: “a 3.7 cm turn to the right == a headshot.” In reality, it’s not about recording specific movements, but about forming the ability to effectively adapt to different conditions, to conduct analysis.
When it comes to aim, the brain and nervous system learn not to remember mouse positions, but to solve motor tasks: “The target is moving like this, I need to apply a force of this specific strength and duration.”

Sens-Schizophrenia: The Perfect Sens is an Illusion

Acolytes of the cult believe that by finding their perfect sensitivity (let’s say, 52 cm/360), they will reach nirvana. But the world is unstable. What happens if:

• You change your mousepad/skates to slightly slower/faster ones
• A speck of dust gets on the skates
• The weather brings higher humidity – the mousepad becomes a bit slower
• You’ve worn a slow spot on the mousepad, where movement in the center is slower than on the edges

Any of these micro-changes completely invalidates the idea of memorized movements. With your ideal 52 cm/360 sensitivity, you de facto need to apply different amounts of force to perform the same movements expecting the same result. And if you rely purely on muscle memory, you will miss (You perfectly applied the force for a 10cm movement to the left, but the mouse traveled only 9.5cm or a full 10.5cm). Because your brain expected one level of resistance but got another.

Aim is Basketball: An Analogy

A basketball player throwing the ball into the hoop doesn’t calculate millimeters or reproduce a shot memorized down to the nanosecond. They assess the distance, the defenders’ movements, their own momentum, and adapt the shot on the fly. They rely on a general feel for their body, the ball, and the hoop’s position. They can score from different positions, with different approaches, using one or two hands, with or without wind, even with balls of different weight and bounce. Because they have developed general coordination, not memorized one specific shot.

It’s the same with a cracked aimer. They don’t remember how many centimeters to move the mouse for a headshot from Mirage’s fireboxes into pit, they don’t know what hand movement is needed to turn 20°. They see the target, their brain instantly assesses the distance from the crosshair to the target and the target’s movement speed, and their arm, wrist, and fingers cooperate to solve this task. The composition of this “cooperation” will change depending on the sensitivity.

• On a low sensitivity (50 cm/360) the main work is done by the forearm and shoulder for large turns, while the wrist and fingers make micro-corrections.
• On a high sensitivity (20 cm/360) the wrist and fingers are actively engaged, while the movement from the shoulder and forearm is reduced.

The perfect aimer isn’t the one who memorized one sensitivity, but the one who developed neuromotor control that allows them to effectively use any sensitivity to solve the task. Depending on the task – the sensitivity can be different – for arena shooters a faster sens might be more convenient, while for tactical ones – a slower one.

The Visuomotor Feedback Loop

When you grind an aim trainer for hours, you’re not training your arm muscles. You’re training the speed and efficiency of the feedback loop:

1. Eye: Sees the target and its movement.
2. Brain: Processes the visual information and calculates the necessary motor command.
3. Hand: Executes the command.
4. Repeat the cycle: analysis of the previous result.

The essence of training is to shorten the time it takes to complete this loop (reduce analysis time) and increase the accuracy of the calculation in step №2. Muscle memory here is not memory of the movement, but memory of how different motor commands correlate with the result on the screen. It’s a skill of calibration, not reproduction.

Conclusion

An obsession with muscle memory and the search for the “one true” sensitivity is a dead end. It creates a fragile system that collapses at the slightest change in conditions.

The true skill of aiming is not muscle memory, but visuomotor coordination. It’s the ability of your brain and body to quickly and accurately adapt to any conditions: a new sensitivity, a different gameplay style, a changed situation. It’s about plasticity, not rigidity. You need to develop not the memory of the hand, but the connection between the eye, the brain, and the hand. And then you’ll have that cracked aim.

With regular aim training – changing sensitivity stops being noticeable – you can easily jump between 24-34-38-44-55-66-77-88 (etc., etc.) cm/360 without feeling much difference – the speed of adaptation to new conditions will take mere seconds.

Не запоминание, а адаптация

Главное заблуждение - представление о мышечной памяти как о жесткой записи в нейронах: «поворот на 3.7 см вправо == хедшот». На самом деле, это не запись конкретных движений, а формирование способности эффективно адаптироваться к разным условиям, проводить анализ.
В случае с аимом мозг и нервная система учатся не запоминать положения мыши, а решать моторные задачи: “Цель движется так-то, нужно применить усилие такой-то силы и длительности”.

Сенса-шизофрения: идеальная сенса — это иллюзия

Адепты культа верят, что найдя свою идеальную сенсу (условно, 52 см/360), они достигнут нирваны. Но мир нестабилен. Что будет, если:

• Ты сменил коврик/глайды на чуть более медленный/быстрый
• На глайды попала пылинка
• Погода прокнула повыешнную влажность - ковёр стал чуть медленее
• Ты натёр слоу-спот на ковре, движение в центре медленее чем по краям

Любое из этих микро-изменений полностью инвалидирует идею о заученных движениях. С твоей идеальной сенсой 52 см/360 де-факто необходимо прилагать разные усилия для совершения одинаковых движений в ожидании одного результата. И если ты уповаешь на чистую мышечную память, ты промажешь (Ты идеально приложил усилия на движение 10см влево, но мышь прокатилась лишь 9.5см или целых 10.5см). Потому что твой мозг ожидал одного сопротивления, а получил другое.

Аим - баскетбол: Аналогия

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

Точно так же и жоский аимер. Он не помнит, на сколько сантиметров нужно сдвинуть мышь для хедшота на Мираже с фаирбоксов в яму, он не знает какое движение рукой ему нужно сделать чтоб повернуться на 20°. Он видит цель, его мозг мгновенно оценивает расстояние прицела до цели и скорость передвижения цели, и его рука, кисть, пальцы кооперируются, чтобы решить эту задачу. Состав этой “кооперации” будет меняться в зависимости от сенсы.

• На низкой сенсе (50 см/360) основную работу выполняет предплечье и плечо для крупных поворотов, а кисть и пальцы вносят микро-коррекции.
• На высокой сенсе (20 см/360) в дело активно вступают кисть и пальцы, движение плечом и предплечьем сокращается.

Идеальный аимер — это не тот, кто заучил одну сенсу, а тот, кто развил нейромоторный контроль, позволяющий ему эффективно использовать любую сенсу для решения задачи. В зависимости от задачи - сенса может быть разной - для ареновых шутеров более удобна будет быстрая сенса, а для тактических - медленная.

Зрительно-моторная петля

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

1. Глаз: Видит цель и ее движение.
2. Мозг: Обрабатывает визуальную информацию и вычисляет необходимую моторную команду.
3. Рука: Выполняет команду.
4. Повтор круга: анализ результатов прошлого

Суть тренировок - сократить время прохождения этой петли (уменьшить время на анализ) и повысить точность расчета в пункте №2. Мышечная память здесь - это не память о движении, а память о том, как разные моторные команды соотносятся с результатом на экране. Это навык калибровки, а не воспроизведения.

Вывод

Зацикленность на мышечной памяти и поиске “той самой” сенсы - это путь в тупик. Он создает хрупкую систему, которая рушится от малейшего изменения условий.

Настоящий навык аима — это не мышечная память, а моторно-зрительная координация Это способность твоего мозга и тела быстро и точно адаптироваться к любым условиям: к новой сенсе, другому геймплею, изменившейся обстановке. Это пластичность, а не жесткость. Разивать нужно не память руки, а связь между глазом, мозгом и рукой. И тогда будет ебочка.

При регуляных тренировкая аима - смена сенсы перестаёт ощущаться - ты можешь спокойно скакать между 24-34-38-44-55-66-77-88 (и т.д. и т.п.) см/360 и при этом не особо ощущая разницу - скорость адаптации к новым условия будет занимать считанные секунды.

am rly like this blobby dancer. Its the best nvidia tech demo ive ever seen.

am rly like this blobby dancer. Its the best nvidia tech demo ive ever seen.

В мире киберкотлет, кибершпротов и хардкорного гейминга культ аиминга возведен в абсолют. Часы на тренировочных картах, бесконечные дуэли, дроч в аим тренерах и погоня за идеальной сенсой, мышкой, ковром, глайдами, посадкой, разрешением, fovом и т.д. и т.п. - всё это ритуалы современного неопилигрима, верящего, что скорость реакции и точность мыши доведут его до топ-1. Но по факту жоский анализ бол-ва игор оказуаливает аим как ключевой навык. В большинстве современных мультиплеерных компетитив игр “чистый” аим намеренно поставлен разработчиками в подчиненное положение. Его потенцевал жеско ограничен системами, призванными уровнять шансы между игроками разного уровня мастерства.

Великий уравнитель: Рандом, мувмент и неконтролируемые факторы

Главный враг raw-скилла аиминга - это случайность и ограничения. Разработчики давно воткнули, что игра, где победа безраздельно принадлежит тому, у кого быстрее реакция и лучше mouse-контроль, обречена на узкую аудиторию (серия quake в качестве примера). Новые игроки будут уходить, с болью в попе, а матчмейкинг не справится с гигантским разрывом в скилле между вершиной и низом.

Поэтому в ход идут системы-костыли:

• Random Bullet Spread (RNG Spread): Самый очевидный пример. Даже в самом популярном тактической шутере Counter-Strike, который считается эталоном киберспорта (ну как минимум он самый популярный), пули из любого оружия в стоячем положении летят не строго в одну точку, а в пределах некого круга разброса. В Valorant этот разброс еще более выражен. Нет возможности гарантированно контролировать каждую пулю - можно лишь увеличить вероятность попадания. Это огромная разница - Даже заученный спрей-паттерн - это не точная наука, а танцы с бубном вокруг случайного отклонения (пжзарегай).
  

• Контроль скорости передвижения: Ключевой, но часто упускаемый из виду аспект. Во многих играх (CS2, Valorant, R6 Siege) базовая скорость передвижения персонажей относительно низкая и предсказуемая. Это мощнейший инструмент уравнивания. Против медленной цели и новичок, и про будут целиться практически одинаково эффективно. Разница в их скилле будет минимальна. Гений трекинга не сможет раскрыть свой потанцевал, просто потому, что цель не бросает ему вызов. Вся “вилка” между плохим и хорошим аимом сжимается. Разница же ощущаестся когда появляется быстрая, непредсказуемая цель. Здесь нуб просто потеряется и не сможет по ней попасть, в то время как жоский-игрок, хоть и с худшим результатом, чем против медленной цели, всё же сможет её оттрекать. Таким образом, медленный мувмент - это скрытый механизм, не дающий сильному аимеру раскрыть свой полный потанцевал против слабого оппонента.
  

• Стрельба в движении: Механизм, практически полностью убранный из тактических шутеров. В том же CS стрельба на ходу - это синоним слова “промах”. Это сознательное решение, которое переводит акцент с пострелушек на позиционирование и тактику (стоп-шоты).
  

• Система промахов (Bloom), уменьшение урона на дистанции, сложная баллистика — все это слои RNG, которые добавляют в уравнение фактор удачи. Иногда кривой выстрел попадет, а идеально наведенный - нет.
  

Суть идеи - снизить ceiling (потолок) мастерства аима. (невелировать aim-advantage) Разница между хорошим и богоподобным аимером нивелируется тем, что даже бог не может гарантировать попадание из-за рандома, а против медленной цели его превосходство будет не так заметно. Новичок всегда имеет шанс на случайное попадание или “счастливый” хедшот.

Высокий TTK vs Низкий TTK: Парадокс аим-зависимости

Здесь кроется главный парадокс, который многие не осознают.

• Низкий TTK (Time To Kill): Характерен для тактических шутанов (CS2, Valorant, R6 Siege). Убийство происходит за 1-2 попадания. Казалось бы, тут нужен ювелирный аим, чтоб давать по шапке с пермой. Но на деле аим менее важен, чем кажется. Решающим фактором часто становится не чистое попадание, а: Позиционирование (можно застать врага врасплох, дать одну по затылку, сделать килл даже не начиная дуэли), Знание углов (префы, оффэнглы и т.п.), Удача (Случайная пуля залетела в лицо. Новичок просто дёрнул рукой, стрельну на бегу/в прыжке и шотнул куда более сильного игрока)
  

• Высокий TTK: Классика для ареновых шутеров (Quake, Apex Legends, Overwatch 2, The Finals). Здесь чтобы убить врага, нужно непрерывно трекать его и попадать в него много раз подряд. Случайно затрекать в течении десятка секунд просто не получится.
  

И вот здесь raw-аим выходит на первое место. Удачным выстрелом тут ничего не решить. Нужно именно долго и точно вести цель. В играх с высоким TTK разрыв в мастерстве аима между игроками виден значительно больше. Сильный игрок будет стабильно оттрекивать и убивать новичка, у которого просто не хватит точности и контроля над мышью, чтобы нанести достаточно дамага. Тактикой и позицией тут проблему не решить - нужно именно попадать, но можно пытаться вывозить на мувменте, но тут опять же расширяется вилка aim-advantage исходя из пунктов выше.

Бегство от аима: Тактика, мувмент и абстрактные способности

Поскольку чистый аим - навык сложный, требующий тысячи часов на оттачивание, разработчики уводят фокус в другие, более “демократичные” механики:

1. Тактика и коммуникация. Можно очень плохо двигать мышкой, но постоянно удивлять соперника, занимать неожиданные позиции, давать коллы для коммандой работы, юзать абилки.
   
2. Мувмент. В так. шутерах он работает как ограничитель (медленный и предсказуемый). В ареновых - как разделитель (быстрый и сложный), позволяющий сильному игроку доджить и демонстрировать превосходство в трекинге.
   
3. Способности (Abilities). Мощнейший инструмент для делевелизации аима. Зачем идеально целиться, если можно закидать соперника гранатами, турелями, смоками, всякими слоу-спотами и флешками. Эти механики требуют не точности, а правильного принятия решений и тайминга.
   

Вывод

Аим, безусловно, остается важным навыком. Но бол-во компетитив игр задезайнены так, чтоб оказуалить его, сделать одним из многих факторов победы, но не единственным и уж точно не основным (решающим). Медленный мувмент, RNG разброс и обилие абилок - это дизайнерская философия, направленная на то, чтоб игра оставалась доступной для миллионов, а не для горстки избранных с идеально отточенной моторикой.

am rly like this blobby dancer. Its the best nvidia tech demo ive ever seen.

Core Concept

The Russian layout is built as a phonetic analogue of the English one:

• A > А
• R > Р
• S > С
• T > Т
• G > Г

and so on, where possible.

This approach means you don’t have to learn a new layout from scratch - you can start typing confidently right away, knowing only the base layout: many words and combinations are typed with similar finger movements regardless of which layout you’re using.

Why It Works

Letter and sound frequencies in Russian and English are largely similar. Therefore, phonetically mapping the English layout to Russian provides a reasonably good distribution of workload without requiring separate deep optimization for Russian texts. (Russian, English)

Heatmap

Top 1000 words for Russian and English

You can poke around and compare on my visualizer:

heatkeys.sccl.cc (you can poke it right here!)

What’s Here?

One of the features of Colemak CAWS is the central block of keys with symbols:

- [ \ / ]

Because of this, the layout feels almost like a split keyboard: there’s additional space between the hands, and some rarely used symbols end up under the index fingers.

In the Russian version, this space turned out to be perfect for letters:

Щ, Ш, Э.

They’re not used that often, but they’re significantly more comfortable to press than in traditional layouts, where such letters are usually relegated to the right pinky.

Not all phonetic correspondences are obvious. For example:

• V → В
• W → Ж

This mapping might look strange, but it’s actually historically accurate.

The remaining letters had to be shoved wherever they’d fit:

• Ъ ended up under the pinky, much as I’d prefer otherwise, since it’s used extremely rarely.
• Ю took the place of \. This letter isn’t too frequent either, so this turned out to be the least painful placement option.
• Ё - some idiot in the Russian layout stuck it in the ass-end of the world - in this variant it’s on Е, but on the AltGr layer.

The layout doesn’t try to be perfect for Russian. The goal was to make the Russian part as similar as possible to the English one, so you don’t have to keep two different layouts in your head, while preserving the ergonomics and convenience of Colemak.

Compatibility

The layout was made for ANSI keyboards.

On ISO it might work slightly differently.

On Split I use the regular phonetic DH.

Installation for Windows

The layout was built using Microsoft Keyboard Layout Creator (.kdl file for editing is in the archive)

It’s better to drop the DLL files manually and register them in the registry by hand too.

But you can run the installer and pray the system doesn’t croak.

Download archive:
rumkcaws.7z

Linux

No version for Linux, I use split and DH there anyway - the layout itself is basically for a laptop.

U can create an xkb config using xkb.sccl.md

Основная идея

Русская раскладка построена как фонетический аналог английской:

• A > А
• R > Р
• S > С
• T > Т
• G > Г

и так далее, где это возможно.

Такой подход позволяет не учить новую раскладку - на ней можно печатать сразу уверенно зная лишь основную: многие слова и сочетания набираются похожими движениями пальцев независимо от выбранной раскладки.

Почему это работает

Частотность букв и звуков в русском и английском языках во многом схожа. Потому фонетическое отображение английской раскладки на русский язык даёт достаточно хорошее распределение нагрузки без отдельной глубокой оптимизации под русские тексты. (Русский, Англиский )

Heatmap

Топ-1000 слов для русского и англиского

Почекать, сравнить можно на моём визуализаторе:

heatkeys.sccl.cc (можно потыкать прям тут!)

А чо тут?

Одной из особенностей Colemak CAWS является центральный блок клавиш со знаками:

- [ \ / ]

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

В русской версии это место отлично подошло для букв:

Щ, Ш, Э.

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

Не все фонетические соответствия очевидны. Например:

• V → В
• W → Ж

Такое сопоставление может выглядеть странно, но оно вполне исторически достоверное.

Остальные буквы пришлось пихнуть куда впихнётся:

• Ъ отправился под мизинец, как бы того мне хотелось, поскольку используется крайне редко.
• Ю заняла место \. Буква тоже не слишком частотная, поэтому это оказался наиболее безболезненный вариант её размещения.
• Ё какой то идиот в русской пихнул её в жопу мира - в данном варианте она на Е, но на слое AltGr

Раскладка не пытается быть идеальной для русского языка. Задача была сделать русскую часть максимально похожей на английскую, чтобы не приходилось держать в голове две разные раскладки, но сохранить эргономику и удобство от Colemak.

Совместимость

Раскладка делалась под ANSI-клавиатуры.

На ISO она может работать немного не так.

На Split я использую обычный фонетический DH.

Установка для Windows

Раскладка собрана через microsoft keyboard layout creator (.kdl файл для редактирования в архиве)

Лучше закидывать dll ручками и прописывать их в реестре тоже ручками.

Но можно тыкнуть установщик и молиться, что система не помрёт.

Скачать архив:
rumkcaws.7z

Linux

А для лини нет, я там использую split и dh, сама раскладка, по сути, для ноута.

Можно накидать xkb конфиг с помощью xkb.sccl.md

A novice’s request to “pls coach me” often puts an experienced player in a difficult position. They possess a skill that has been honed to the point of automatism, to a pure feeling. The first problem they encounter is the inability to convey this feeling. The answer “just hit your shots,” while truthful, is absolutely useless for someone who hasn’t yet experienced or understood this “just.”

To help, the experienced player takes a logical step-deconstruction. They break down the holistic skill into its component parts.
Each of these components is a high-level abstraction, created to simplify the transmission of a complex ability. In theory, this should help the novice transition from a state of not understanding to their first real experience.

Overanalysis

On one hand, a beginner might be able to extract something useful for themselves. However, it can also happen that instead of a holistic sensation of “tracking the target with the crosshair,” they start agonizing over a dozen isolated parameters, like: “Now I need to track precisely along the trajectory, controlling the speed, and now the target has sharply changed direction-I need a flick, but without overflicking, to jump onto the target smoothly yet quickly.”

A simple action becomes burdened by the need to simultaneously control all these concepts created “for simplification.”

The Inadequacy of Abstractions

Over time, it becomes clear that any created model is incomplete. It fails to convey the pure feeling, that very kinesthetics of aim-the fusion of eye, hand, and mouse into a single action. The model itself begins to demand simplification.

And then a new level of explanation emerges, an even higher-level abstraction, such as:

• “Just play more”
• “Just track the target and hit it”
• “Don’t shake, but you can tense your arms as much as you want”
• “Lead the target with your gaze, and your hand will follow automatically”

This is the purest truth. This is exactly how all experienced players operate-they can perform at a sufficiently high level on autopilot. But for a novice, who is still struggling with basic concepts, this advice sounds like mockery.

The Ultimate Solution

In the end, the circle closes. All the complex explanations and multi-layered abstractions lead to the only working solution that has always existed: “Watch how others do it and try to replicate it until you succeed.”

This is not merely an evasion. It is an acknowledgment that some skills cannot be conveyed through words and diagrams. They can only be absorbed through observation and built up through thousands of repetitions. Practice, in the end, dissolves all abstractions, returning the player to the very starting point of the question-to that intuitive “track the target smoothly with your crosshair and strive to hit more.” But now, this “just” is backed by real, rather than theoretical, experience.

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

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

Черезмерный анализ

С одной стороны новичок сможет чота для себя выдернуть полезное, но может быть и такое, что вместо целостного ощущения “вести прицелом по таргету” - он начинает мучительно думать о десятке изолированных параметров, аля: “Сейчас нужно трекать ровно по траектории, контролируя скорость, а теперь цель резко сменила вектор движения - нужен флик, но без оверфлика, чтоб плавно, но быстро прыгнуть на таргет”.

Простое действие утяжеляется необходимостью одновременно контролировать все эти созданные “для упрощения” концепции.

Неполноценность абстракций

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

И тогда возникает новый уровень объяснений, еще более высокоуровневая абстракция аля:

• “Just play more”
• “Просто веди по таргету и попадай”
• “Не трясись, но руки напрягать можешь сколько угодно”
• “Взглядом веди таргет, а рука сама повторит”

Это и есть чистейшая правда. Именно так и делают все опытные игроки - они на автопилоте могут сыграть на достаточно высоком уровне. Но для новичка, который все еще борется с базовыми концепциями, этот совет звучит как издевательство.

Ультимативное решение

В итоге круг замыкается. Все сложные объяснения и многослойные абстракции приводят к единственному работающему решению, которое существовало всегда: “Смотри, как делают другие, и пытайся повторить, пока не получится”.

Это не просто уход от ответа. Это признание, что некоторые навыки невозможно передать словами и схемами. Их можно только перенять через наблюдение и наработать через тысячи повторений. Практика в конечном счете растворяют все абстракции, возвращая игрока к тому, с чего начинался вопрос, - к тому самому интуитивному “веди прицелом ровно по таргету и стремись попадать больше”. Но теперь это “просто” подкреплено реальным, а не теоретическим опытом.