Прочувствовал боль всего linux-сообщества

Выложил ttop в Arch/AUR. Можно ставить yay -S ttop

И хотел было запаковать ещё в deb, rpm и т.д. но, оказалось, что простого способа ещё не изобрели. Я-то думал какую-то тулзу/сервис уже давно придумали и положили в github actions, - не могут же люди в 21м веке руками писать кучу всяких BUILDPKG, spec, DEBIAN/control и тд, которые делают в моём случае одно и тоже. А нет, могут и пишут и потом ещё плачут и поддерживают это всё. Добавлю что это всё должно бы автоматически обновляться из тегов и над тобой уже нависает гора проблем.

В общем нытья у меня набралось на целый пост, однако оказалось, что небожители уже поныли за меня: https://www.youtube.com/watch?v=Pzl1B7nB9Kc . Но вывод тут глобальнее - о всех проблемах linux-desktop из-за этой проблемы со сборкой пакетов.

Мне казалось, что это типичная проблема которую можно было бы решить ещё одним стандартом включающие все остальные. И оно бы сработало, но, почему-то вместо этого придумали ещё более слоёный пирог в виде flatpack, snap и appimage. Удивительно, но в 21м веке оказалось что самый нормальный способ достался нам от мамонтов, а именно это static (+musl опционально)

#linux #ttop

RefCell - трусы надень или крестик сними

Когда-то давно написал статью https://habr.com/ru/post/442962/, но, и до этого, и во время написания статьи меня не покидало ощущение, что костыль RefCell<> ломает всю концепцию borrow-checker'а, хотя это и является одной из базовых вещей в Расте. Использовать её, всё равно что использовать unsafe, но чуть с менее печальными последствиями. Программа в определённый момент может тебе сказать, причём уже только в runtime: "тут мои полномочия всё, ты как-нибудь сам", и, скорее всего, это будет значить что что-то в приложении заархитектурено не так и надо начинать сначала.

С Rc<> проще, но к нему тоже претензии - в каком-нибудь single-threaded-async он не нужен, но в расте он будет нужен только для удовлетворения borrow-checker.

#rust

Alpine linux

В подтверждении проблем производительности MUSL о которых упомяналось тут: https://telegra.ph/Testing-Alternative-C-Memory-Allocators-Pt-2-The-MUSL-mystery-02-04, тут https://lists.alpinelinux.org/~alpine/users/%3C6df8863e77b970b466dbfc9a3a5c2bcec3199f48.camel%40aquilenet.fr%3E и тут https://t.me/inv2004_dev_blog/26

> ./rosettaboy-* -H -S -t -p 10 ../opus5.gb

ubuntu> release => Emulated 16700 frames in 10.00s (1669fps)
ubuntu> lto => Emulated 21200 frames in 10.00s (2119fps)

alpine> release => Emulated 15865 frames in 10.00s (1586fps)
alpine> lto => Emulated 18035 frames in 10.00s (1803fps)

#linux #musl

Удалёнка. Технические моменты. 1/2

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

1) полная автономность

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

2) полу-автономность, типа VPN к работе

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

3) полная удалённость

3.1) типа RDP

Этот вариант последние пару лет был мой основной - интернет есть почти везде, а небольшие разрывы связи не так и сильно раздражают если это только на картинку влияет. Я пользовался anydesk и getscreen и, в целом, для неторопливого кодинга вполне подходит. Даже если пропадает интерфейс, то на удалённой машине всё остаётся стабильно - быстрый интернет, большая мощность не зависит от батареи - приятный бонус, несмотря на визуальные небольшие лаги. Все эти RDP довольно хорошо оптимизированы, не смотря на то, что как правило работают через промежуточные сервера, даже на плохом мобильном интернете лаги приемлемые.

#нищета_it

Удалёнка. Технические моменты. 2/2

3.2) типа SSH

Всегда хочется лучшего, я как-то подумал, чего мне гонять целый экран, когда я пользуюсь в основном терминалом. И, какого же было моё удивление, что SSH лагает значительно больше чем getscreen. Если команду в терминале набрать ещё ок, то работать в vim/micro (типа лёгкая IDE) - вообще не вариант. Оказывается, это проблему пытаются решить через mosh (https://github.com/mobile-shell/mosh), но, как обычно, непопулярные технологии непопулярны. я вот про него только на этой неделе узнал. Основная фишка его: local echo и udp. Естественно, прокинуть udp, это непозволительно в энтерпрайсе и понятно почему он не очень-то взлетел. Вторая проблема - он не умеет прокидывать порты. В общем-то всё равно vim/micro даже по mosh не слишком рабочая связка (через ssh вообще неюзабельно - я про случай с заметным пингом). И ещё раз удивляюсь что всё это тормозит очень заметно сильнее чем getscreen через пару серверов. Где же лёгкие терминалы - мне казалось это летать должно при современных скоростях.

3.3) типа VSCode

Естественно, самая зрелая альтернатива - vscode-remote. Писать банальности про клиент-сервер нет смысла, гораздо интереснее, что он, оказывается, даже терминал запускает не через ssh, а через ssh-порты и свой сервер. И, что совсем удивило, что этот хитрый vscode-terminal умеет этот самый local echo как в mosh, т.е. набирая буквы - они печатаются сразу, но серым текстом, а когда удалённая сторона подтверждает ввод - становятся белыми.

Так что, похоже, придётся оставить все попытки мигрировать с vscode на vim/micro. В текущем варианте без vscode не обойтись. Хотелось бы чтобы он восстанавливал соединение быстрее (как mosh) - с этим пока проблемы

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

#нищета_it

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

Это sapling-csm - альтернaтива git (написано на безопасном языке Rust)

#нищета_it

Очередная спец-олимпиада, но, на этот раз, немного более практичная: https://github.com/shish/rosettaboy. Эмулятор gameboy одинаково реализованный на нескольких языках.

Автор запускает на Mac+clang, я на WSL2+gcc

В целом - просто хотел сказать что если счёт не идёт на наносекунды, то разница в основных претендентах минимальная и можно писать на том что больше нравится. Аргументы о тормозящем GC часто тоже не особо рабочие

#bench #rust #nim #cpp

Напиши пост о том как меня чуть не бомбануло от IndexDefect в Nim, но потом я осознал что это нормально

### Предупреждение: этот текст может вызвать эпилепсию

Здравствуйте! Сегодня я хочу поделиться с вами своим опытом работы с языком программирования Nim и IndexDefect.

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

Однажды я столкнулся с проблемой, которая почти заставила меня бросить работу с Nim. Я пытался выполнить операцию индексации в массиве, но каждый раз получал ошибку IndexDefect. Я попробовал все возможные способы решения этой проблемы, но ничего не работало.

Я чувствовал себя очень разочарованным и фрустрированным. Я даже подумал, что это ошибка языка программирования Nim и что я никогда не смогу нормально работать с этим языком.

#### ^^^ Единственное что правильно

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

Таким образом, я нашел решение проблемы: я начал более внимательно следить за индексами массивов и убедился, что они находятся в допустимых пределах.

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

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

### потом будет нормальным текстом. просто хотел сравнить

#gpt #nim

Странная жаба

Долго выбирал зарядку для ноута, причём жаба такая - 2800р дорого, надо дешевле, потом долго провод для зарядки выбирал: 1000р дорого, надо за 600р - кучу обзоров посмотрел/прочитал и тд. Но всё равно ворочался с бока на бок и не мог уснуть. А потом, докинул за 5000р+ тестер/осцилограф для проверки всего этого говна (жаба при этом даже не квакнула) и уснул спокойно.

Не понятно как это так устроено.

О больном

Эльбрус, Байкал, Arm, CISC, RISC-V и тд и тп. В чём проблемы (спойлер - в менеджерах). Интересные особенность Эльбруса: три стэка и 128битный режим, количество регистров

https://youtu.be/G56lE2407Ls

У нас первый раз менеджеры предложение/комментарий сгенерили в chatgpt и запостили в issue. Я так понимаю, ожидалось, что я это прочитаю и аккуратно этот бред разберу и вычленю важное оттуда. Но, что-то внутри меня останавливало делать это. В итоге, я всё же сообразил, что это палка о двух концах - попросил chatgpt сгенерировать ответ на это и запостил обратно. Вроде всё честно и вроде пообщались. Как говорится - теперь мячь на их стороне. Ловко я выпутался

#gpt

Вышел Nim 2.0

Основное, конечно, это Arc/Orc сборщики мусора

https://nim-lang.org/blog/2023/08/01/nim-v20-released.html

#nim

Обновил bios, устал

Частично согласен с Тонским https://t.me/nikitonsky_pub/507, пользователи - тестеры. А 100+ программистов не хватает, чтобы сделать простые вещи. Например, обновить биос в своём lenovo.

Началось всё так: я прочитал, что если основной сценарий использования ноутбука от розетки, то для этого надо бы включить какой-то специальный режим зарядки только до 80%. Включить его можно только в какой-то lenovo-утилите - Lenovo vantage размером 500Mb+. Утилита умудряется делать всё: показывать рекламу новых ноутбуков, какие-то видео, но найти там одну нужную кнопку не так и просто. И конечно, эта программа не просто программа, но и сервис, который включается навсегда. Сервис постоянно что-то от тебя хочет, я успешно всё это игнорировал, но одно обновление довольно обнаглело - попап из ниоткуда, раз в день, что надо обновить биос. Посопротивлявшись месяц, я решил - хорошо, с bios можно понять что это только к компетенции леново, так что я в итоге согласился. Чтобы избежать ещё одного сервиса обновлений в системе я решил сделать руками - скачал bootable iso (так и написано) с сайта, однако, rufus отказался его распознать. примонтировав в linux - в этом iso было тоже пусто. Ладно, нажал на скачивание этого обновлятеля биосов - он распаковался, запустился и тут же показал ошибку, что система не опознана. Я даже логи нашёл рядом, но это не помогло. В общем я сдался - пусть качает утилиту обновления сам - удалю потом. При установке этой утилиты два раза на 30 секунд отключался тачпад - это как вообще. Потом появился диалог что ничего нельзя вообще делать - ни вынимать питание, ни жать на кнопки и двигать крышку экрана и что система перезагрузится через 5 минут, и кнопка Ok, нажав на которую ноутбук перезагрузился сразу. Сделав какие-то тайные действия он рассказал что биос состоит из 8192 блоков и даже нарисовал прогрессбар для этого действия, что удивительно - кривой (картинка https://t.me/inv2004_dev_blog_chat/337), все блоки по 4 дефиса, но самый левый 3 дефиса. Он обновился и перезагрузился. Перезагрузился ещё раз, при этом только мигала лампочка рядом с кнопкой питания. Помня что ничего делать нельзя я ждал минут 5, но не выдержал и нажал. Тут же появилась страшная надпись - BIOS проверяет своё здоровье и проценты, после того как проценты стали 99% они исчезли и заменились на "...", прошла минута ожидания непонятно чего и тут ... у ноутбука с дикой силой начал работать вентилятор, что он никогда не делал раньше, по крайней мере чтобы это было так заметно. Явно происходит что-то мощное, что именно - не понятно, мой пульс заметно поднимается, что делать - не понятно. Но, слава компьютерным богам, через пару минут, всё же он перезагрузился и всё закончилось благополучно. Но осадок, как говорится, остался, и, кажется, раньше было как-то проще, несмотря на то что приходилось руками это обновляет из файла.

#нищета_it #lenovo

Не про саму книжку, а про чтение подобных книг и code review

Чтение этой книжки - 250 страниц, заняло больше года. 130 страниц за несколько часов в самолете и 120 страниц еще 6 месяцев. Если отбросить художественную литературу, то я не понимаю как подобное можно проглотить с нормальной скоростью. Хотя эта книга в основном довольно простая, но, всегда встречается большое количество неочевидных вещей, каждая из которых закапывает тебя всё глубже, и, иногда, чтобы было полное понимание, надо старые issues или код компилятора смотреть. Как простой пример - реализация != (не равно) через шаблон. Первая, мысль при чтении - логично и просто. Вторая мысль - но ведь можно через женерики ... при условии их inline-оптимизации. В итоге пишешь на форум, где отвечают что это исторически так сложилось. И это самое простое из всего. Такого накопать в каждом втором примере можно, в итоге, пробраться через это раскопав всё до твёрдой поверхности понимания это как раскопать древний город. Получается некое review книжки. Собственно, что review (а не его имитация) занимает время сопоставимое, а то и больше, с написанием - и была моя основная мысль

Why is Rust println! slower than Java println?

https://reddit.com/r/rust/s/hXPNlrnZaQ

> I think, that javas println is optimized and rust isn't. The reason why rust is not, could be that it doesn't matter. Rust doesn't want to be a language that can print fast. It has other priorities

#rust

Про upwork - качели летят вниз

Довольно плохая была идея оставлять upwork надолго. Не смотря на относительно спокойные пару лет, вероятность того, что стартап пойдёт вверх минимальная, как бы хорошо технически вы его ни сделали. Как следствие => деньги имеют свойство заканчиваться, в продукте больше нету каких-то важных задач, потому что задача одна - продать хоть что-то чтобы удержаться на плаву. Но дело не в этом, если раньше на upwork я имел бейджик Top Rated Plus, что значит ты входишь в 3% фрилансеров, то теперь у меня нету никакого бейджика вообще. Это, естественно, максимально отодвигает тебя в видимости для клиентов. Оно было бы в целом логично, если бы не ситуация, что аккаунт который был top rated plus имеет меньше смысла чем только что зарегистрированный, по той причине, что всем новым дают Rising Talent, что заметно лучше чем ничего

#upwork

Чистый кот

Покопавшись в новом коде (golang, если это важно) я обнаружил довольно большое обилие интерфейсов, которые легко можно было бы удалить - они ни на что не влияли. Но решил подтянуть данную тему.

Ещё заранее стало понятно, что это про около-SOLID концепт "чистый код". Я не против и не за, у него есть и плюсы и минусы, но, по некоторым аспектам у меня возникают вопросы:

- Все статьи на эту тему начинают с одного и того же примера: делаем интерфейс доступа к базе (шаблон repository) чтобы можно было его имплементировать для нескольких баз. Мотивируется это так: вдруг вы с postgres на монгу переехать захотите. Подобный пример, конечно, можно ожидать в реале, но, как по мне, всё равно является довольно рыхлым. Я не верю в простой переезд с sql на nosql и обратно для какого-то проекта более чем todo. Мотивация номер два - реализовать и для postgres и для sqlite, потому как программисту тяжело запускать postgres локально. С этого момента уже хочется начать хихикать, представляя какое количество дополнительных проблем принесёт подобный подход, где фундамент проекта отличается при разработке и эксплуатации кардинально. Хочется добавить, что, наверняка в языке и так есть абстракция для sql баз, где для замены базы надо заменить только дравер.

В моей голове так сложилось, что интерфейсы появляются в момент когда две сущности выполняют один контракт, но, все попытки выйти на две сущности в примерах выше выглядят странно. Но, тут фокусник снимает шляпу, и из шляпы появляются юнит-тесты и mock, именно юнит. У вас есть какой-то код, но не придумывается вторая сущность? - тогда этой сущностью будут тесты для этого кода, у любого кода есть (должны быть) тесты, следовательно, есть вторая сущность, следовательно, всё должно быть максимально абстрактным.

И этот логический выверт, из-за отсутствия примеров получше, мне и кажется странным, т.е. тесты натягивают на себя код а не наоборот. Опять же, я не хочу сказать, что этого быть не должно, - каждый для себя решит TDD или не TDD, но, подавать это как единственно правильный вариант для всего - мне кажется странным. Добавлю, что если заменить юнит-тесты интеграционными, что я встречал довольно часто, то эта концепция опять разваливается.

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

— added —
Хороший пример удобства данной концепции, который мне привели - кеширование

#golang