Я не фанат, але на сьогоднішній конфі Xbox (яка була найпотужнішою за весь Summer Game Fest) показали трейлер S.T.A.L.K.E.R. 2 українською! 🫶 Дякую GSC Game World за те, що це зробили, та Microsoft за те, що підтримали.

Є у мене в домашній мережі купа self-hosted сервісів, значить. Більшість у докері. А проблема з докером у тому, що він порти на хостовій машині займає, так їх ще й памʼятати треба (або записувати кудись). І якось не прикольно потім у браузері писати та бачити http://myserver:53412.

Як сервер у мене Synology NAS наразі, і там є вбудований реверс-проксі. Цього було б достатньо, щоб зробити собі адреси виду http://myserver/gitlab, але хочеться радше http://gitlab.mynetwork. Тож підняв я додатково DNS-сервер (також від Synology, хоча там, мабуть, тільки юайка їхня) і зрозумів, що це дуже прям запарно налаштовувати тепер. Доводиться в декількох місцях одне й те саме прописувати.

Виявилося, що замість повноцінного DNS-сервера в локальній мережі можна використовувати mDNS, проте, з ним також є певні проблеми. А для більш-менш автоматичного налаштування реверс-проксі можна було б перейти на Træfik чи Caddy. Та це вже якось вище мого порога заморочливості.

Тож я здався та спробував Tailscale. Це така штука, яка дозволяє дуже легко та швидко побудувати свою VPN.

Ідея звісно не нова: ще на початку 2000-х ми з друганами думали, як нам грати разом в ігри, якщо ми живемо в різних районах. У першому StarCraft можна було, наприклад, зателефонувати модемом напряму модему другана, прикиньте ☎️ Але то поодинокий випадок скоріш. А ось десь у 2004-му зʼявилася така славнозвісна в ті часи прога як Hamachi (на скріншоті саме вона). Вона дозволяла змусити ігри думати, що два віддалених компи насправді в одній локалці — те що треба!

Зараз такі штуки теж існують. Наприклад, ZeroTier. Ми з ексколегою намагалися через нього пограти віддалено в Cuphead, але воно зрідка давало неприємний лаг. (Ми з ним пограли врешті, але інакше).

Так ось, а шо Tailscale? Ну більшість з вас, мабуть, вже й так в курсі — це тільки я слоупок. Але фактично це те саме, тільки на базі (дуже швидкого) протоколу WireGuard, й до того ж підтримує меш-мережу.

Цікаве тут інше: tailscale можна підіймати прямо в докер-контейнері, фактично додаючи його у вашу мережу як окрему машину. Тобто виходить наче у вас є окремий комп, на якому стоїть тільки той сервіс, який ви там підняли. Отож з суботи я займався міграцією деяких штук у свій новий tailnet.

В принципі, процес доволі straight-forward. Налаштував собі простий GitOps для автоматичного деплоя ACLs та docker-compose.yaml файлів. Наче норм.

Але зʼявилася зворотна проблема: не всі сервіси легко підіймаються на 80-му порту 😤 Це тому, що перші 1024 порти привілейовані, й вішатись на них можуть тільки проги з відповідними правами. Однією з неспроможних штук виявився форк Gitea — Forgejo, який я вирішив собі підняти замість GitLab (бо останній заважкий для моїх потреб). Танцював навколо нього майже дві доби, але так і не зміг змусити його забайндити на себе 80-й порт. Зрештою довелося в контейнері ще підіймати nginx чисто заради цього.

Запрацювало тепер-то! Можу відкривати http://git/ та насолоджуватися 😎 (причому навіть не вдома, бо у мене навіть на телефоні Tailscale).

Цікаво до речі, що сучасні програми вкрай кепсько реагують на подібні короткі адреси: телеграм не запарсив як URL (з міркувань безпеки, я думаю), браузери постійно намагаються відкрити мені пошук замість сайту, а Arc навіть не зміг зберегти закладку 🤡 Я не кажу вже про http (без s). Але це вже інша історія.

Обожнюю отримувати такі автоматизовані листи з систем наших клієнтів 🥸😅

Як же складно (і прикольно) мати свій домашній сервачок, жах!

В принципі Tailscale справді дещо спростив. Але пару додаткових днів я все-таки вбив: то зовнішні адреси не пінгуються, а тільки адреси з tailnet, то навпаки, то і ті, й інші відвалилися, то на хостовій системі ок, а в контейнері адреси не резолвляться, то контейнери з restart: always не рестартують (до речі хз чого). Ну а зрештою взагалі випадково вбив свій інстанс ґітлабу, тому що запустив два контейнери, обидва з яких писали в одну теку.

Tailscale зручний, та все ж далекий від ідеалу. Наприклад, на macOS у них аж три різні офіційно підтримувані версії з різним набором фічей, а на моєму Synology він працює з низкою обмежень. (До речі в обох випадках головна завада — системний сендбоксинг). Одначе користуватися цим можна.

Єдине, що не подобається — залежність від їхнього сервера. Він виконує тільки адміністративно-координаційну роботу на щастя, і все ж!

У попередньому дописі я згадував Tailscale мого дитинства — Hamachi. І знаєте, що з ним трапилося? Він перетворився на лайно 💩 Сталося це в ту мить, коли його купила угорська компанія 3am Labs, яка згодом стала називатися LogMeIn, яка до речі пізніше купила й LastPass, а ще пізніше злилася з дочірньою компанією Citrix, що робила GoToMeeting та інші продукти з тієї ж серії, тож зараз вона так і називається — GoTo. Якщо ви колись користувалися LastPass (у яких вже регулярно крадуть користувацькі дані), «новим» Hamachi або GoTo Meeting, то нескладно помітити коричневу марку якості.

Як же себе захистити від подібного з Tailscale? Ну, на щастя їхній демон та CLI-клієнт — повністю open-source. Сервер ні, проте, вони не забороняють використовувати якийсь свій, тож це було питанням часу, коли хтось напише власний. Чекати довго не знадобилося: наразі існує доволі фічастий Headscale. Тож виходить, що в принципі можна все потрібне заселфхостити.

Що саме Tailscale дає особисто мені? Ну, декілька речей:
• легке налаштування віддаленого доступу до якихось селф-хостед речей без необхідності випускати їх в публічний інтернет. Тобто не треба прокидати порти кудись назовні, морочити голову з DNS або DDNS тощо, а потім трястися, що хтось підбере твій qwerty123. У мене серед таких речей мій ґіт-сервак, книжки, скани документів, база хавки, Home-Assistant і т.д.
• легша взаємодія зовнішніх сервісів (low-code платформи для автоматизації або тих же GitHub Actions) з цими внутрішніми штуками. Робиться це завдяки ефемерним ключам, наприклад: у вас на раннері запускається пайплайн, авторизується в tailnet (з відповідними правами), спілкується з потрібною нодою, а потім видаляється з мережі щойно йде офлайн (в кінці workflow).
• швидке перекидання файлів між пристроями а ля AirDrop.

Поки це всі юзкейси, може згодом ще щось знайду. А зараз відчуваю, що досить — моя devops-чаша вже переповнена ))

C++-комітет продовжує підглядати в спеку Haskell обговорювати нові потенційні фічі для мови. Цього разу (документу вже рік насправді) дійшло до плейсголдерів _, щоб зручно було користуватися зіставленням із взірцем (паттерн-матчінгом), якого звісно досі нема, або, наприклад, розпаковувати кортежі на кшталт:

auto [x, y, _] = f();

Тут типу третє значення нам не суттєве, тож можна використати _, щоб не вигадувати імʼя, а потім боротися з ворнінгами про те, що воно не використовується, додаючи [[maybe_unused]].

Та C++ би не був собою, якби все було так прозоро. Ніщо не заважає вам і зараз використати _ як імʼя змінної:

auto [x, _] = make_pair(1, 2);
cout << x << "," << _ << endl;  // використання

Тож це працюватиме й надалі. Однак інколи хочеться зробити так двічі в одному скоупі, а structured binding — це визначення нової змінної, а не просто запис у ту, що вже існує:

auto [x, _] = make_pair(1, 2);
auto [_, y] = make_pair(3, 4);

Зараз такий код генерує error: conflicting declaration ‘auto _’, бо це повторна декларація змінної, а от з новим пропоузалом перестане.

Тобто можна навіть вручну скільки завгодно разів оголошувати змінну _, і жодних проблем… доти, доки не спробувати звернутися до змінної _ у цьому ж скоупі. Якщо вона оголошена один раз, то можна, а якщо декілька, то це помилка:

auto _ = 42; // Оголошення
auto _ = 0;  // Повторне оголошення
{
    auto _ = 1; // Новий скоуп. Оголошення з шадовінгом
    assert( _ == 1 ); // Можна прочитати
}
assert( _ == 42 ); // Не можна прочитати 🙂

В принципі, очевидно, еге ж?) А, до речі… У неймспейсі двічі не можна оголосити:

namespace a {
    auto _ = f();  // Ок
    auto _ = f();  // Помилка
}

Все логічно, короч 🤡 Ні, заждіть, це не жарт. Все справді логічно, якщо над цим поміркувати достатньо довго! Але капець, як же втомлює тримати подібні нюанси в голові весь час.

З іншого боку шанси, що це увійде в C++26, все одно низькі ) Може в C++32…

Взяв я собі ж R1, як вже згадував. Тижні три чи чотири лежав у мене — ліньки було розпаковувати.

Відтоді, як я його замовив, в інтернетах вже зʼявився 1000001 відос про те, який це скам. І скоріш за все так воно і є. Та я не жалкую, бо разом з ним я отримав річну передплату на Perplexity (власне, за ціною річної передплати). Тож сприймаю це як безплатний пристрій 😅

Що сказати по самому девайсу… Пластик відчувається якимсь дешевим, але загалом пристрій дуже solid. Українською запити ігнорує, але коли просиш перекласти щось з української іншою мовою — робить це без проблем. Концептуально дуже схоже на кишенькову Amazon Alexa, тільки розумнішу й водночас менш спроможну. Alexa хоча б світло може вимкнути 😁

З інтеграцій є тільки Spotify/Apple Music, Uber, DoorDash, Midjorney та Suno. Я ще не настільки сказився, щоб логінитися під своїми акаунтами на чиїхось ремоут-компах, тож протестувати, мабуть, не вийде. Та й нагадую, що їхня хвалена LAM (Large Action Model) наразі виявилася пачкою кривих скриптів під Playwright.

Ютубери та інші тиктокери вже так затролили їхню ШІ-шку, що коли показуєш Реббіту в камеру коробку від харчової добавки, що ветеринар виписав коту, й просиш розказати, що це, воно замість інформації видає текст на хвилину про те, чому воно не може давати мені медичні поради, і як це все небезпечно, і наскільки воно відповідальне і т.д. Доволі useless короч.

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

Ніхто не вміє робити теги правильно. І я теж, але обговорімо.

Взяти, наприклад, Paperless. Це така система для керування та пошуку по відсканованим документам. Автори кажуть: «теки ми не зробили, бо є теги». Типу, хочеш згрупувати декілька елементів — використовуй тег. І в принципі норм, а шо, хоча відчувається якось неприродно час від часу.

В іншій програмі — у Raindrop, де я зберігаю закладки — можна і теги додавати, й ієрархічні колекції створювати. За наявності ієрархії мозку одразу стає легше, бо є якась структура, по якій можна просуватися, варто лише початок обрати. Це корисно, якщо щось шукаєш, і не певен, що саме, або якщо просто хочеш глянути, а що є взагалі.

Та з ієрархією неодмінно настане момент, коли не зрозуміло, в яке місце додавати новий елемент, а дублікати створювати не хочеться. Ось є у мене ієрархія тек по мовах програмування: ну, там… C++, Haskell, JavaScript, Red тощо. І тут я хочу зберегти посилання на бібліотеку Slint, яка є і для C++, і для Rust. Тож в яку теку її додавати? Або, уявімо, що теки були не по мовах, а по категоріях: DB, Network, UI й т.і. Тоді куди тут додавати Qt, якщо він чудово справляється з усіма ними? Ну ви зрозуміли. У такому випадку зазвичай як раз достатньо обрати якийсь один варіант для утворення ієрархії, але для пошуку всі характеристики краще перелічити як теги.

Тут виникає інша проблема. Якихось характеристик, властивих поточному обʼєкту може бути ну дуже багато! І ніколи не знаєш, які треба додати, а які не обовʼязкові — дізнаєшся це, вже коли намагаєшся знайти щось, і не виходить 😖 Одного разу я автоматизував собі додавання усього, на що я ставлю зірочку на ґітгабі, у Raindrop зі збереженням тегів. І тепер у мене 2500+ тегів, з яких, мабуть, 80% зустрічається в _одиничному_ екземплярі серед усіх 1600+ закладок. Бо люди на ґітгабі теж не знали, які теги варто додати, а які ні.

Або ще проблема. Ось є у мене в закладках якісь відеоредактори: чи має бути тег #відеоредактор, чи все ж #відео та #редактор? Чи може всі три одночасно?

А ще дратує, коли якісь суто технічні обмеження для тегів створюють: тільки маленькі літери, без пробілів, без дефіса, без інших символів тощо. А якщо немає цих обмежень, то теж погано: починаєш думати, чи маленькими літерами все писати, чи великими? Має бути #javascript чи #JavaScript, чи може #js або #JS?

Obsidian, в якому я це пишу, пішов далі й дозволив ієрархічні теги. Це в принципі вирішує низку проблем. Наприклад, я можу створити тег #редактор/відео і швидко знайти саме відеоредактори, але також можу і побачити взагалі всі (уявімо, що там текстові, аудіо-, графічні й т.і.), якщо шукатиму чисто по #редактор. Зручно? Зручно.

А втім… Зваживши все, що я написав раніше, чи бачите ви проблему?

Саме так! Це ж та сама ієрархія, але вже серед тегів. Тобто й обмеження, й решта проблем всі ті ж самі. Візьмемо #arduino, наприклад. Куди його покласти: в #залізо чи у #бібліотека для C++? Адже насправді воно і те, й інше.

Тож вже напрошується єдиний правильний висновок: треба дати можливість тегати теги!

І тоді при пошуку можна буде брати як той тег, що безпосередньо був обраний користувачем, так і теги, які йому належать. Якщо ви шукаєте щось по тегу #залізо, то ймовірно хочете побачити там і те, що стосується #arduino. Якщо у вас є тег #FreeRTOS, то він сам може бути протеганий як #Amazon, #real time, #MIT license, тоді як #real time стосуватиметься #operating system, а #MIT license належатиме до #open source. Тоді шукаючи за тегом #Amazon ви автоматично знайдете все, що цим тегом явно позначено не було, але було позначено як #FreeRTOS.

Звісно, є й зворотна сторона. Наприклад, ви шукаєте #open source, і воно, розмотуючи ланцюг, знаходить тег #FreeRTOS, яким ви позначили щось, що стосується FreeRTOS, але само по собі при цьому зовсім не обовʼязково open source.

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

Це я мрію зробити собі прогу для каталогізації мотлоху, що у мене є, тож розмірковую з приводу організації.

Я сам кіберспортом не цікавлюся, а ось технологіями навколо — інколи буває. Сьогодні про клавіатури хочу сказати.

Наразі вже певний час триває (повторний) розквіт механічних клавіатур, який для мене особисто почався більше 10 років тому з купівлею клавіатури на Cherry MX Blue. У ті часи перемикачів в принципі було 4 доступних: сині, коричневі, чорні та червоні. Ще пара людей могла щось чути про Topre, та то скоріш виключення. Зараз же перемикачів існують сотні: ті, що клікають при натисканні, ті, де відчувається «сходинка», лінійні, тихі та не дуже, з різним зусиллям, від різних виробників, побудовані за різними принципами тощо. Зʼявляються регулярні порівняння, відбуваються холівори, та довгий час незмінним лишався один факт: перемикач лишався просто перемикачем — тупо boolean ввімкнено/вимкнено. Решта вже снобізм та смаки, як на мене. (У мене до речі Gazzew Boba U4, якщо це комусь про щось скаже. Мій вердикт — норм 🙂).

На моєму обрії все змінилося, коли на кікстартер вийшла Wooting зі своєю клавіатурою one. Сама по собі вона була не надто цікава на відміну від оптичних перемикачів, на яких вона базувалася. Оптика дозволила не просто реєструвати факт натискання, а реагувати на глибину. Я сам граю майже виключно іксбоксовим геймпадом 🎮, тож для мене цілком нормально контролювати в іграх дії, як-от швидкість руху, дуже точно, не кажучи вже про можливість відчувати те, що відбувається на екрані, завдяки haptic feedback. І це сильно відрізняється від досвіду гравців на клавіатурі та миші, де ти ніби перебуваєш у пласкому цифровому світі — наче деякі відчуття заблокували. (Але у людей там свій фан, не будемо кейборд-шеймити тут 😂).

Так ось… а тут раптом клавіатура на оптичних сенсорах! Звісно, ця функціональність має додатково використовуватися авторами гри, наприклад, щоб зробити плавний перехід між ходою та бігом, тож може це одна з причин, чого я довгий час згадок про Wooting не чув. Втім, з цікавого, зокрема для ігор, була можливість налаштовувати так звану точку спрацьовування — момент, коли, власне, перемикач реєструє зміну свого стану — тоді як інші механічні перемикачі мали цю точку сталою.

Чого здатність повільно ходити в грі не може зробити, так це продати комусь клавіатуру. Тому Wooting вигадала невеличку оптимізацію під назвою Rapid Trigger, яка потенційно давала відчутну перевагу у змагальних іграх. Ідея у тому, що замість перемикання у якійсь конкретній точці світч реагує на зміну напряму руху. Іншими словами, ви натиснули кнопку, й щойно почали її відпускати, як клавіатура перестала слати для неї івенти. Якщо знов донизу пішло, знов надіслали. Це дозволяє ніколи не натискати та не відпускати кнопку до кінця, що стає в пригоді в іграх. Razer, SteelSeries та інші теж «надихнулися» та зробили у своїх пристроях таке.

Wooting пішла ще далі. По-перше, виявилося, що оптичні сенсори не дуже точні при максимальному натисканні. А по-друге, вони… бруднилися 🚯 Тож компанія перейшла на сенсори на ефекті Холла. Але цікавішою була їхня подальша оптимізація Rapid Trigger, яку вони назвали Rappy Snappy. Тут вже стало очевидно, що цільова авдиторія — це саме геймери. Короч, ідея у тому, що можна повʼязати дві кнопки з «протилежними» діями, наприклад, вліво/вправо або вгору/вниз, та реєструвати натискання тільки однієї з них — тієї, що натиснута глибше — бо мати їх обидві одночасно натиснутими все одно несе небагато сенсу в більшості ігор (бо у такому випадку гра зазвичай ігнорує обидві).

І ось не так давно Razer відповіла на це власною варіацією під назвою Snap Tap. Замість того, щоб покладатися на те, наскільки глибоко кнопки натиснуті, вони реагують на останню зміну стану (натискання/відпускання). Таким чином можна, наприклад, тримати одну кнопку завжди натиснутою, а іншою змінювати напрям руху.

Що там ще цікавого навигадували? Хтось в темі?

Це трохи нагадує мені так-званий one-pedal drive, що нині є в деяких гібридних та електроавтівках. Там ідея у тому, що натискання педалі — це прискорення, а відпускання — це гальмування. Я якось пробував, й мені не зайшло. Та мабуть все впирається у звичку.

Тут чувак у сусідньому каналі (Я вже рекомендував? Рекомендую!) пише, мовляв, подивіться, як програмували у 90-х… скільки коду треба було написати, щоб зробити просту програму.

Ну, я подивився. А там приблизно те саме, що я й зараз пишу 😅😭 Тільки розмірність вікон та координати значно менші )

Щось десь краєм вуха чув про GraalVM, але сильно не цікавився. Виявляється, можна нині скомпілювати джаву в нативний бінарь без JVM, і це дає реальний приріст як по CPU, так і по пам'яті 👇