Sergey Matveev [Wed, 9 Dec 2020 08:59:15 +0000 (11:59 +0300)]
Не привет
https://neprivet.ru/
https://gist.github.com/ValdikSS/570631cca891719a770c
https://valdikss.org.ru/smart-questions.html
https://www.nohello.com/
При обсуждении 6855f1c4e5ade25cfd4a97941ce6dab32cedb18a, вспомнились
ссылки с рекомендациями как задавать вопросы в электронной переписке. У
ValdikSS взял все эти ссылки. Вообще чуть ли не в каждом крупном проекте
ПО есть похожие рекомендации и даже шаблоны где человека *сразу* просят
рассказать суть проблемы, что было предпринято, и т.д..
Как грамотно задавать технические вопросы, чтобы эффективно общаться
и получать ответы (версия ValdikSS):
Многие молодые люди привыкли к синхронному тет-а-тет общению в
интернете, никогда не писали бумажных писем, из-за чего не умеют или
не осознают, как эффективно задавать вопросы технического толка.
Если вы хотите задать вопрос, пишите так, чтобы собеседнику всё было
понятно без дополнительного расспрашивания:
* Начните с короткой формулировки проблемы. Ёмко опишите, что не
работает или не получается сделать.
* Опишите проблему в деталях. Разъясните в сообщении, какой
результат вы получаете, а какой должен быть на самом деле. Укажите
ваше оборудование и версии ПО. Лучше написать больше информации,
чем что-то упустить.
* Опишите ваши действия, которые вы предприняли для решения
проблемы. Специалисты часто ожидают, что вы проделывали какие-то
действия для решения проблемы до того, как задаёте вопрос. Если вы
совсем не разбираетесь в теме, что даже не знаете, с чего начать —
так и напишите, чтобы не складывалось ложного впечатления, что вы
просто ленивый.
* Отправляйте сообщение и ожидайте ответа. Некоторые проблемы
требуют раздумий и длительной подготовки ответа, будьте терпеливы.
* Помните: чем точнее и полнее вы сформулируете вопрос, тем больше
шансов, что вам ответят. Уважайте собеседника, и собеседник будет
уважать вас.
И вот хорошо сказано что это реально всё не понятно людям привыкшим к
синхронному общению. Кто ничего из списка из коробки делать не будет. В
итоге эффективность работы/общения/кооперации явно невероятно низкая. И
дав таким людям email, они же и в нём будут так же писать.
И я неоднократно получал вопросы по PyGOST/ещё чему то в духе описанном
на neprivet.ru: "можно задать вопрос?", я отвечаю, через полдня мне
придёт вопрос. Меня просто даже удивляет мотивация задавать вопрос о
вопросе. Мне кажется шансы что человек вас пошлёт, не будет общаться,
будет слишком занятым, куда меньшие чем то что он пойдёт навстречу и
выслушает. Поэтому почти с 100% вероятностью инициатору придётся всё
равно написать свой вопрос. А раз всё равно писать, то зачем этот лишний
round-trip? Более того, часто бывает что инициатор думает что у него
большая проблема, требующая долгого объяснения/решения, хотя она на
самом деле такая мелочная глупая, что её решение сразу же понятно у
ответчика и не займёт много времени, как бы он ни был занят.
me: "Hi"
them: "Hello"
me: "How's your day been?"
them: "fine"
me: "Crazy weather"
them: "yeah"
me: "Do you have a second to chat about ABC"?
them: "Just a sec"
me: "Ok"
them: "Ok, shoot"
me: "Do you if PDQ about ABC?"
them: "Oh yeah, it's 123"
Sergey Matveev [Wed, 9 Dec 2020 08:32:41 +0000 (11:32 +0300)]
Как же тут не любят Ruby
http://harmful.cat-v.org/software/ruby/
Забавное собрание цитат про Ruby:
Ruby is Scheme mated with Perl in such a way that the best genes of
both failed to exert a phenotype.
ruby is what happens when some kid learns java then looks at perl
and thinks ‘I can fix this!’.
Everything you heard about Ruby being slow is not true. It’s about
twice as slow as that
Ruby performance tuning really feels like trying to get the best
miles per gallon out of a tricycle.
Ruby performance tuning also feels like trying to bail out the ocean.
At least Perl is hilarious. Ruby does not have the redeeming quality
of being funny.
irb(main):003:0> ''.methods.length
=> 176
А я ведь в 2000-х писал на Ruby и Ruby On Rails. В принципе то жить
можно было, хотя и казалось что это тоже такой Perl, где вот 176 методов
только для пустой строки. Небольшая скорость тоже запомнилась. Но особо
негатива не осталось, хотя я тогда ещё и совсем молодой был. Но когда я
увидел Django и Python, то тогда Ruby полностью забросил и забыл про него.
Sergey Matveev [Wed, 9 Dec 2020 08:27:27 +0000 (11:27 +0300)]
Посмотрел "После прочтения сжечь"
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D0%BB%D0%B5_%D0%BF%D1%80%D0%BE%D1%87%D1%82%D0%B5%D0%BD%D0%B8%D1%8F_%D1%81%D0%B6%D0%B5%D1%87%D1%8C
С одной стороны, это конечно не шибко то и комедия, ибо куча людей
мёртвых, сплошные измены и страшная деятельность ЦРУ. Но с другой, такая
глупость, с точки зрения стороннего наблюдателя (ЦРУ), такая фигня
выходит, просто потому что люди оказывались не во время не в том месте,
что выходит очень забавно! Собственно, чёрная комедия. Очень понравилась!
Sergey Matveev [Tue, 8 Dec 2020 19:41:14 +0000 (22:41 +0300)]
AirPods Max
https://habr.com/ru/news/t/532008/
Безусловно только Apple может предоставить наушники за 62 тыс. руб., но
даже не показать АЧХ. Ладно, даже не написано какие частоты то
воспроизводит уж. Вообще ничего про звук... ведь это же наушники, кому
он нужен? Think different! Мне казалось что начиная с 2-х тыс. руб. для
наушников это уже всё будет указываться.
Плюс ещё очень важен вес. Каждые десятки грамм, по своему опыту, знаю
что сильно влияют на возможность долгого ношения. Мои Байеры 290г
весят, а AirPods на сотню грамм больше. В них конечно и электроника и
аккумуляторы, ничего удивительного, но это точно не для долгого ношения.
Sergey Matveev [Tue, 8 Dec 2020 19:21:21 +0000 (22:21 +0300)]
Почему Vi использует hjkl клавиши, а в JS месяц с нуля?
https://www.hillelwayne.com/post/always-more-history/
Просто любопытное копание в истории почему так всё устроено. Про vi я
знал. Также ещё и факт что Esc на клавиатуре находился на месте Tab и
поэтому легче нажимался чем сейчас. Про даты я конечно догадывался что
для оптимизации, но не знал что они так заморочено хранятся в памяти.
Sergey Matveev [Tue, 8 Dec 2020 14:08:32 +0000 (17:08 +0300)]
github.com/agl/xmpp-client XMPP клиент на Go
У меня уже прилично времени нет установленного XMPP клиента. Давным
давно, я пользовался mcabber и был им полностью доволен. Одно с ним
большое но: он не поддерживает несколько учётных записей -- нужно
запускать несколько программ.
Когда Google, Facebook, ВКонтакте прикрыли возможность его
использования, то почти все люди исчезли из мира Jabber.
На работе его использовали, но из-за желания использовать мобильные
устройства, он тоже отпадает, ибо, насколько понимаю, нету для мобильных
ничего нормально работающего, кроме централизованной проприетарщины. И
на работах всех Jabber исчез. Но для всяких решений типа Mattermost и
Slack есть мосты для IRC. В ivi какое-то время были попытки использовать
IRC. На следующей работе тоже, даже использовали, так как связь с
XMPP-сервером паршивила.
В итоге я уже много лет использовал irssi и bitlbee, который снёс когда
Jabber полностью пропал даже на работах. Но всё же учётные записи у меня
остались и есть люди с которыми крайне редко, но нужно связаться через
него.
И вот попробовал xmpp-client -- для супер частого постоянного
активного использования (которого в IM-ах у меня уже много лет нет в
принципе) он наверное не очень удобен, но в остальном имеет всё что
надо. Все базовые фичи Jabber поддерживает, управляет ростером,
статусами, показывает изменение статусов собеседников, даёт
многострочные сообщения вводить, из коробки сразу же OTR автоматический.
Состоит ровно из одного бинарника, без Си зависимостей. Один JSON
конфиг, автоматом создаваемый. OTR ключ в нём же хранится, как и
отпечатки ключей собеседников. SMP OTR поддерживается. Редактируемая
строка ввода, разукрашенный вывод. В общем, для себя взял на заметку что
если нужно быстро и просто поднять клиент, то это отличный вариант. Если
не нужен MUC (тут уж другие клиенты нужны), передача файлов и подобное.
MCabber ещё надо ставить, собирать зависимости, да и конфиг править.
Bitlbee аналогично, плюс вспоминать как пользоваться, ибо его help-ы и
дока запомнились не лучшей точностью, болью и страданиями при работе с
MUC. Но bitlbee приятен тем, что для всего используется один irssi
(например), а он уже является мостом и можно несколько учётных записей
использовать.
Sergey Matveev [Tue, 8 Dec 2020 11:34:25 +0000 (14:34 +0300)]
Хлеб в холодильнике
У некоторых людей я видел такое, когда вместо хлебницы хранят в
холодильнике. И мне не нравилось что он холодный -- хотелось хотя бы
комнатной температуры. Но в итоге, с переездом, как стал жить один, сам
стал так делать. Ибо он хранится существенно дольше. Один я не съедают
батон чтобы он не успел начать портится.
Sergey Matveev [Tue, 8 Dec 2020 07:36:37 +0000 (10:36 +0300)]
Клетки Фарадея для дома
https://habr.com/ru/news/t/531850/
Люди покупают эти клетки для защиты от "вредоносного" 5G, но жалуются
что что-то сигнал плохо и ничего не работает. Ну эту новость не
переплюнет ранее написанная с амулетами супротив 5G: 19f39a3de479bc9ab31c12f2d4ff79b5d65dad41.
А вообще если нужно действительно оградить себя от как-то оказавшегося в
квартире какого-нибудь iPhone-а, который и не выключить и аккумулятор не
вынуть, то клетка бы пригодилась. Но вот у меня дома "из коробки" ни
одного места нет где бы сотовый не работал: микроволновка идеально
пропускает GSM (конечно, если её включить, то через некоторое время
сотовый точно не будет ничего передавать). Отец предложил холодильник,
но там у меня не было сомнений что дохлый номер. Коробка полностью
металлическая из под чая, закрывающаяся плотно -- ухудшает сигнал, но
всё равно он работает.
Раньше были проездные от электрички и метро -- помещал их в
собственноручно сделанный чехол с кучей фольги. Дело ещё с института
было. И вот через несколько слоёв фольги ни Bluetooth устройства, даже
вплотную к USB-приёмнику, не работали, ни сотовые, ни, соответственно,
RFID/NFC карты. А с переездом на электричке стал ездить так редко, что
использую одноразовые билеты. И с коронавирусом в метро тоже по
одноразовым стал, ибо редко вылажу.
Sergey Matveev [Sun, 6 Dec 2020 15:00:48 +0000 (18:00 +0300)]
Новая коллекция GNU проекта о запланированном устаревании
https://www.gnu.org/proprietary/proprietary-obsolescence.html
Как и ожидалось, Apple, Google, Samsung и их устройства в которые
заложены тормоза и просто неработоспособность после какого-то времени.
Не забуду свой Panasonic CD-плеер, который подарили на день рождения,
тогда же он, соответственно, был включён первый раз, а ровно через год,
буквально на следующий ДР, он просто так перестал включаться совсем
(хотя его не били и был в отличном состоянии).
Sergey Matveev [Sun, 6 Dec 2020 14:58:51 +0000 (17:58 +0300)]
Статья про квантовые компьютеры, в том числе и про криптографию
https://habr.com/ru/post/480480
В тему b9198692a94e3f931bee4b7411a84ca0a9577a02 статья о квантовых
компьютерах интересная с попытками разъяснить это на пальцах.
Sergey Matveev [Sun, 6 Dec 2020 11:44:42 +0000 (14:44 +0300)]
В Prey серверы с VGA и жёсткими дисками
В добавок к d62cebfa50b82f8e2f859ce94ee9c78e44511ae2: в одном месте там
видны стоечные серверы и их задницы. И RJ45 и VGA до сих пор всё точно
так же используются. А то находятся люди которые считают что VGA уже
сейчас умер -- надо постараться найти сервер без него! Хотя меня тоже
удивляет, что, в казалось бы, весь из себя цифровом компьютере,
продолжают использовать аналоговый сигнал для визуализации информации.
HDMI всё же дороже чем ЦАП? DisplayPort, в виду своей природы, насколько
понимаю, ощутимо сложнее устроен и требует больше "мозгов". Или HDMI всё
же действительно в целом паршиво работает, как вот у меня в ноутбуке
(да, до сих пор его иногда приходится подключать по VGA!)? Или лицензии
какие-нибудь стоять на HDMI/DP так, что проще ЦАП засовывать? Или просто
тот факт что и мониторов много только с VGA до сих пор, а их, в свою
очередь, потому что серверов/компьютеров? У меня дома ни дома, ни на
работе нет никого где бы ни было VGA. Хотя нет и ни одного монитора где
бы не было, в добавок, и DVI, в который зачастую можно HDMI конвертировать.
Sergey Matveev [Sun, 6 Dec 2020 10:28:18 +0000 (13:28 +0300)]
Может нам всё же не нужен децентрализованный web?
https://withblue.ink/2020/11/12/maybe-we-shouldnt-want-a-fully-decentralized-web.html
https://news.ycombinator.com/item?id=25312854
Человек был увлечён IPFS, хостил в нём свои творения, что-то писал,
ратовал за свободу слова, а потом решил забить на всё это и прекратить
поддерживать IPFS и связанное с ним. Мне статья понравилась тем, что
пересекаются мысли в ней с моими во многих отношениях.
Автор, по моему, всё же мешает цензуру/свободу с
централизацией/децентрализацией. Связь между ними конечно есть, но всё
же натянутая зачастую. И в централизованной системе можно обеспечивать
анонимность, конфиденциальность, безопасность. И в децентрализованной
устраивать цензуру. Но буду считать что он просто вот так эти термины
решил использовать.
Его мысли близки к моим относительно Tor-а, выходную ноду которого, не
говоря про релейную, я держал не один год. Уже не раз писал, но
повторюсь что Tor-у, как проекту, я просто не доверяю что их мотивом
является свобода/анонимность/бла-бла-бла: чисто технически у них
централизованная БД нод, централизованное управление поведением сети и
её участниками (собственно, тоже цензура), при этом нет защиты
анонимности от злоумышленника государственного уровня и ничего для этого
не предпринимается. Ответом на последнее могло бы быть: используйте I2P,
если нужна более сильная и надёжная анонимность. Но а Tor тогда что и
для чего? Я его вижу и воспринимаю исключительно как инструмент для
обхода цензуры сетевой. И исключительно для целей (ведь никто и не
скрывает что оно и создавалось и спонсировалось ВС США) пропаганды США.
Любое творение может использоваться и во вред и для блага. А основной
прогресс делают для военных целей, потом уже применяя в быту и для
благих. Tor тоже можно использовать и для благих целей, как, банально,
например просто для создания относительно доступной тогда входа для
своей ноды, которая может быть за NAT-ом и быть мобильной. Но есть
решения более для этого приспособленные -- Tor излишен. Его можно
использовать *в теории* и для многих других вещей, о которых у них пишут
на сайте. Но... для всего этого чисто технически куда лучше использовать
кучу других технологий (если забыть про размер anonymity set), типа
Freenet, I2P, GNUnet (в теории). А Tor имеет и цензуру и ничего не
делает для улучшения анонимности/whatever, ведь свою основную (как я её
воспринимаю) задачу он выполняет: обход сетевых ограничений вражеских
государств, для пропаганды и помощи оппозиционерам и сепаратистам.
Помогая Tor-у, запуская свои релейные или выходные ноды, я безусловно
помогаю честным людям, которые используют для благих целей. Но при этом
я автоматом помогаю и куда большему кол-ву людей свободословить и
подрывать стабильности гос-в, вешая лапшу на уши, промывая мозги, сея
дезинфу и распространяя слухи. И я убеждён что этих людей *значительно*
больше. В этом абзаце речь только про Tor, про ситуацию на данный момент
(ok, на момент "несколько лет назад", когда я его поддерживал).
Хорошо, возможно я заблуждаюсь и преувеличил и на самом деле людей там
больше которые его используют например для доступа к заблокированным
BitTorrent трэкерам каким-нибудь. А вот тут я считаю что нужно или
переносить по человечески BitTorrent/whatever ресурсы в overlay
цензуроустойчивые сети, или бороться со всякими уродами которые
блокируют подобные ресурсы. Ведь в основном все эти блокировки из-за
сверхбогатых корпораций которым проще просто заблокировать весь трэкер
из-за наличия на нём нескольких нелегально скопированных творений, чем
думать о том какой вред это наносит остальному. Проще заблокировать
львиную долю CDN-ов из-за наличия на них одного ресурса, забывая (и
никогда не зная, на самом деле) про то, что на них тысячи других никак
не связанных.
И вот тут мне цензура не нравится, как осуществляется. Может она совсем
не нужна? Дай волю рыночным отношениями, и "товар" будет предоставляться
теми у кого больше денег/возможностей. Сейчас вон в каждом экспортном
фильме или компьютерной игре из США (да, немного преувеличиваю)
обязательно будет черножопый пидарас трансвестит. Нужно вдолбить что это
нормально. Нужно вдолбить что семейные ценности, честь людей не стоят
ничего и нужно жить только по "рынку". Нужно вдолбить что центром мира
была, есть и всегда будет США. Вдолбить что нужно за всё мстить, есть
только сила и ничего кроме, она всем правит, а темы по доброту,
сострадание и прочее нужно табуировать. Это и сейчас льётся, хотя и не в
таких кол-вах из-за хоть какого-то, но контроля/цензуры. Сколько у нас
народу считает что COVID19-а нет на самом деле и это просто заговор. А
сколько считает что он есть? Сколько уверены что будут "чипированы"?
Сколько уверены что США выиграла Вторую Мировую? Сколько миллионов
уверены в том, что Земля плоская? За считанные дни/недели можно взять и
заставить ненавидеть всех мусульман в мире, как делает Макрон. И список
можно продолжать до бесконечности.
По хорошему конечно же людей надо учить критически мыслить, просто
мыслить, не верить домыслам, неподтверждённым фактам и прочему. Говорить
об этом легко, только сделать сложно, почти невозможно. И делать нужно
заранее, до того как им через соцсети/Tor-ы/whatever начнут вливаться
эти потоки убедительного бреда. Армию нужно вооружить, никто не спорит,
но делать это надо до того, как на неё нападут. А цензура является некой
обороной, сожжённым мостом по которому враг может пройти, которая может
хотя бы оттянуть подготовку. Я вижу как легко молодёжь "заражается"
либеральными взглядами. Вижу что людям проще поступать нечестно и
обманывать корпорации используя Tor, делая jailbrake своих Android/iOS,
вместо того, чтобы не спонсировать и бить "рублём" обнаглевшим Apple и
другим проприетарным корпорациям. Я то помню что даже файл не
скопировать штатными средствами, пока или не поставишь недешёвую софтину
(извините, я отдал XXX тыс.руб., но мне из коробки не дают "проводник"?)
или не сделаешь jailbrake. Tor проще, пару кликов, и вот ты уже смотришь
нелегально скопированное нечто. Jailbrake -- пару кликов и твой девайс
становится юзабельным. Везде есть простые решения: снять проститутку,
своровать что плохо лежит, просто отнять/ограбить у более беззащитного,
купить SIM-ку на вокзале чтобы зарегаться и общаться в VK/Telegram/whatever.
В итоге я и сам не понял какая точно моя позиция. Она точно не бинарная,
поэтому и не могу её точно назвать. С одной стороны цензура мало кому
нравится и это плохо. С другой стороны -- без неё нельзя. Tor я
однозначно бойкотирую и считаю инструментом созданным и, в первую
очередь, используемым для пропаганды. Нужна анонимность -- для этого
есть более достойные, с технической точки зрения, инструменты. Тут для
меня важны мотивы. И если мотивы изначально явно не благие (или я им не
верю, не верю в честность), то тут всё понятно. Пистолет можно
приобрести для убийства, для защиты, для колки орехов, охоты ради еды
или ради забавы. Сейчас Tor это инструмент пропаганды США. А почему бы
его не превратить в инструмент пропаганды РФ, для подрыва и
дестабилизации США? В теории можно. И тогда, поддерживая его, я
поддерживаю техникой страну. И это вроде бы хорошо. Но пока в
информационной войне, как минимум с Tor-ом, мы не так сильны, как наши
враги и поддержка Tor-а это как покупка акций военной компании США
делающей оружие для бомбёжки РФ. Но то, что Tor это инструмент для
пропаганды -- это бесспорно, как и пистолет это точно инструмент не для
колки орехов. И вот у автора статьи про IPFS что-то похожее на всё это.
Ему не нравится пропаганда РФ, пропаганда против геев, ЛГБТ, призывы к
нацизму или против ислама. Мне наоборот не нравится пропаганда США, за
геев/ЛГБТ, но с остальным солидарен. Но он как-то может выразить
(не)поддержку инструментов для этого. Я вот полностью согласен с:
I have seen, and I am seeing every day, the dangers of completely
unrestricted speech, and I don’t want to be the one enabling that.
Я видел не раз во что превращается место в Сети где полностью нет
никакой модерации. Общение с людьми почти невозможно проводить если нет
модерации (что тоже является цензурой). Даже в маленькой рассылке
cryptoparty@ не может не появится срачь, который надо останавливать и
включать модерацию. Люди так устроены. И автор статьи приводит примеры
во что свободословие превращается де-факто всегда.
Некоторые вещи, изначально с плохими/спорными мотивами, могут стать и
благом в будущем, или наоборот. Атомная энергия. FidoNet изначально же
вообще создавался голубыми для общения между собой, а потом вон чем
клёвым стал. И там кстати сильнейшая цензура/модерация по факту.
Возможно первые смартфоны создавались действительно для блага людей, а
теперь это, в первую очередь, крутейший инструмент для слежки и
уничтожения приватности людей. Список, опять же, можно до бесконечности
продолжать. Ну и, как всегда, то что для одного благо -- обязательно
найдётся кто-то другой кому это будет во вред.
Sergey Matveev [Sun, 6 Dec 2020 10:20:28 +0000 (13:20 +0300)]
Распределённый Github
http://radicle.xyz/
http://blog.vmsplice.net/2020/12/understanding-peer-to-peer-git-forges.html
https://news.ycombinator.com/item?id=25313010
Blockchain, какие-то новые транспортные протоколы, потому что NAT
мешает, и куча ещё всяких каких-то идей и задумок. Про себя думаю: что
только люди не придумают, лишь бы не пользоваться email и git-ом
научиться.
Sergey Matveev [Sun, 6 Dec 2020 09:30:59 +0000 (12:30 +0300)]
С отцом затарились в магазине для скейтеров
https://www.dcrussia.ru/mens-collection-acdc/
Кто бы мог подумать что или я или папа по какой-либо причине пойдём в
магазин одежды для скейтеров? Но ради коллекции AC/DC поехали. Я давно,
наверное со школы, никогда не любил спортивную обувь чисто эстетически.
Просто не моё. Но один раз как-то, когда уже и институт закончил, решил
попробовать походить в чём-то не сильно напоминающем спортивную обувь,
но с мягкой подошвой (кеды, кроссовки? не знаю как это называлось). И с
того момента летом стал носить только с мягкой (сильно мягкой) подошвой,
даже не обращая внимание что это и спортивное и не сочетается с
джинсами, кожаной жилеткой, grindcore-футболками и прочим. Удобство
такого уровня что остальное не имеет значения (это только женщины могут
променять удобство на что-то другое)! И вот папе уже наверное с год
советовал попробовал что-то мягкое надеть, ибо ноги существенно меньше
устают. Вот на AC/DC кеды он уговорился.
Sergey Matveev [Sun, 6 Dec 2020 08:57:00 +0000 (11:57 +0300)]
Посмотрел прохождение Prey (2017)
https://en.wikipedia.org/wiki/Prey_(2017_video_game)
Изредка смотрю на современные игры из любопытства. Ну и чтобы просто
быть в теме хоть как-то, чтобы отдалённо представлять что такое FarCry
(хотя первая часть вышла когда я был ещё в школе, но у самого железа не
было чтобы поиграть), Crysis, Halo, Battlefield, Gears Of War,
Unchanted, Dishonoured, Metro 20xx и т.д.. И вот толком сильно ничего не
захватывает. Безусловно смотреть на игру и играть самому это очень
разные вещи! Поэтому против игр ничего не хочу сказать. Bioshock
смотрел, ибо это же как игра из серии System Shock, которую (2-ую) я
обожал! Но... смотреть это одно, а играть -- другое. И смотреть мне
особо не доставляло удовольствия.
Но вот начал смотреть Prey (2017) и меня засосала тематика, сюжет и всё
всё всё. Почти ни разу не промотав в проигрывателе, от начала и до конца
просмотрел, пока ел, пока по мелочам что-то делал рутинное. Вот это
"продолжение" System Shock 2 каким оно и должно быть! Хотя ведь чуть ли
не всё уже реально было изобретено в SS2. Хаки техники, починка,
производство вещей (в SS2 из нанитов), пси, RPG система и прочее. Но в
Prey так всё выглядит сбалансированным, богатым и варьируемым по
возможностям. Музыка атасная для атмосферы этой игры. Модификаций оружия
в SS2 я с ходу не помню, но там была УЖАСНО бесящая порча этого оружия,
возможность его сломать и что оно заклинит. В Prey убрали -- это одобряю.
И сам сюжет жутко интересен. Разнообразные и не шибко мрачные места
действия. SS2 мне запомнился сильно угнетающей атмосферой. А тут и
звуков море и постоянно с тобой разговаривают.
Вовсю надо слушать аудиозаписи и читать чужую почту -- и для получения
кодов и вообще для понимания происходящего. В Doom3 не забуду что это
тоже было, но когда играл в первый раз, то забивал, ибо лень, хочется
бегать и стрелять. И в целом это и никто не заставлял делать -- всё
добровольно. Но на самом деле, без этого будет *крайне* мало амуниция
попадаться. В принципе можно и фонариком бить по голове и считанные
патроны для пистолета считать, но сильно проще всё же читать логи и из
них получать коды доступа к сейфам, где амуниция. Я бы даже сказал что
только так и можно играть по человечески, чтобы не превращать игру в
stealth-partisanen с "ударил, убежал, спрятался, переждал, снова ударил".
Нравится что даже в отдалённом будущем люди всё равно используют именно
email, ибо им нужно работать и использовать подобающий для этого
инструмент. Но не понравилось что даже в этом будущем, нажимая на иконки
интерфейса появляется анимация раскрытия разделов, вместо того, чтобы
быстро и сразу показать запрошенное. Программисты так и не научились там
писать быстрый софт :-)
Sergey Matveev [Fri, 4 Dec 2020 19:14:47 +0000 (22:14 +0300)]
Собаки расстреливают людей
https://lenta.ru/news/2019/10/08/dog/
https://lenta.ru/news/2018/05/10/dog/
https://lenta.ru/news/2017/12/01/friendlyfire/
Новость за новостью о том как собаки то из пистолетов, то из ружей
стреляют в своих хозяев.
Sergey Matveev [Fri, 4 Dec 2020 12:34:27 +0000 (15:34 +0300)]
Moxie не особо понимает как можно доверять одному корню DNSSEC
https://moxie.org/2011/04/11/ssl-and-the-future-of-authenticity.html
https://www.theregister.com/2011/02/18/fed_domain_seizure_slammed/
Намекая что, так как это в США (да и к любой другой стране это также бы
относилось, просто США уже показали свою суть), то в любой момент они
могут заставить сделать всё что угодно. Проблемы CA, как он описывает: и
в том что непонятно откуда у человека появляется доверие к XXX CA, и то,
что даже если Comodo и обосрётся (что уже произошло), то доверие к нему
никуда не денется и его CA сертификаты всё равно останутся в trust
anchor-ах. Причём с DNSSEC-ом всё гораздо хуже, ибо CA для TLS можно
менять, их много, а DNSSEC корень один.
Sergey Matveev [Fri, 4 Dec 2020 11:31:38 +0000 (14:31 +0300)]
О доверии к Apple железу
https://sneak.berlin/20201204/on-trusting-macintosh-hardware/
Оказывается у всего последнего Apple железа нельзя очистить диск/ОС и
установить всё с нуля, пока по Интернету не получить одобрение от Apple,
в виде подписанного сообщения. То есть, без их разрешения, каждый раз
одобряемого, не дозволено на их компьютерах ставить что захочешь.
То есть, для безопасных компьютеров с воздушным зазором (air-gapped),
для тех кто блюдёт криптографическую целостность (полностью очищаемые и
переустанавливаемые системы с доверенного носителя), те кто находятся
вне зоне доступа к Интернету (корабли, как минимум) -- Apple компьютеры
не могут использоваться по определению.
Я вот не сильно против чего имел того, что в ФСБ бумажки делают в Word,
на Windows, но эти компьютеры хотя бы изолированы и не подключены к
Интернету. А с Apple не перестаёшь удивляться их безумным задумкам. И
ещё больше удивляться что пипл это всё равно продолжает хавать.
Sergey Matveev [Fri, 4 Dec 2020 09:22:45 +0000 (12:22 +0300)]
Онлайн-кинотеатры не будут показывать "Криминальное чтиво"?
https://roskomsvoboda.org/67069/
Ну тут конечно сплошное словоблудство, но если представить что
действительно "Чтиво" будет под запретом (одна только клёвая
демонстрация приёма героина чего стоит!), то проще вообще считать
что кино у нас под запретом. Какой смысл в кино, если нельзя такое
посмотреть?
Sergey Matveev [Thu, 3 Dec 2020 12:15:42 +0000 (15:15 +0300)]
Atom комментариев блога тоже отдаёт HTML
В продолжение 259486cf8eb23b982d8b1b846315a5658a7667eb и feed для
комментариев отдаётся HTML-ем. Я просто забыл про комментарии и
поэтому их не сразу переделал вкупе.
Sergey Matveev [Wed, 2 Dec 2020 17:15:28 +0000 (20:15 +0300)]
Анкета после траха
https://lenta.ru/news/2020/12/02/10_iz_10/
Меня вот раздражает когда после связи с техподдержкой какой-нибудь тебе
приходит опросник (по email или SMS). Как и любые оценки людей людьми,
ибо неприятные люди, как бы они хорошо не выполняли работу или что-то
творили на благо -- всё равно будут "заминусованы", ибо большинству
объективность не важна нисколько. А тут вот за границей ещё и женщины
будут присылать анкеты с оценками по десятибальной шкале после "траха".
Что ещё раз говорит о том, что секс для женщин ничего существенного не
значит, поэтому и изменяют легко и обижаются что это не нравится их
мужчинам: "это же просто был трах, а не измена!", ибо "я ж свободная
женщина, фигли меня кто-то будет в чём-то ограничивать, я никому ничего
не должна".
Sergey Matveev [Wed, 2 Dec 2020 13:33:29 +0000 (16:33 +0300)]
Oragono IRC сервер
https://oragono.io/
Что-то вспомнился сегодня Oragono IRC сервер написанный на Go. Пробовал
его устанавливать и с ним работать, проверяя в том числе и irssi работу.
В отличии от моего goircd http://git.cypherpunks.ru/cgit.cgi/goircd.git/tree/README
он конечно громадный монстр по возможностям. Но приятно что в нём сразу
встроены всякие NickServ/ChanServ, bouncer, SASL и куча всего. Его
конфиг огромен! Но особо в нём можно ничего не трогать и всё из коробки
довольно легко и быстро заводится. Если кому-то нужен нормальный
здоровый полнофункциональный IRC сервер, то рекомендовал бы этот. Плюс
он на Go, быстро собирается. IRCv3 поддержка полная, даже с черновыми
CAP-ами.
Sergey Matveev [Wed, 2 Dec 2020 12:59:29 +0000 (15:59 +0300)]
Greylisting -- худшее что случалось с email после спама
http://articles.marco.org/238
Автор пишет что greylisting не работает и, более того, email перестаёт
быть instant-ом! Во-первых, а когда это email был instant-ом, и когда он
вообще предполагался хоть в каком-либо месте архитектуры своей что он
будет работать так? Автор порет чушь. Во-вторых, достаточно включить или
выключить greylisting и посмотреть на практике повлияет ли это на кол-во
спама. Я в этом или прошлом году ради чего-то временно отключил его, а
дальше решил не включать и посмотреть что будет. На глаз спама стало
больше. Включил обратно. Статья -- брехня. Более того, большинство
серверов с которыми моему приходится общаться -- все с greylisting-ом.
Статья правда из 2007-го и наверное с того времени greylisting только
чаще стал использоваться.
Sergey Matveev [Wed, 2 Dec 2020 11:20:48 +0000 (14:20 +0300)]
Прочитал "В сердце Антарктики"
Про путешествие Эрнеста Шеклтона к Южному географическому полюсу (не
дошёл, ещё чуть-чуть оставалось) и достижению магнитного. Как и прежде
(6c1d69c53a59413d51e1075a39857fc91ab40fbb), читать про Шеклтона одно
удовольствие, в противовес путешествиям Скотта, порождающим тонны
возмущения. Шеклтона лично Николай II даже пригласил и наградил, чего не
был удостоен даже Нансен. Сам же Нансен и Амундсен восторженно
отзывались о Шеклтоне и его достижениях.
Sergey Matveev [Tue, 1 Dec 2020 18:34:08 +0000 (21:34 +0300)]
В FreeBSD добавили ядерный WireGuard
https://www.opennet.ru/opennews/art.shtml?num=54178
Полегче! В новом релизе ожидается IPsec ESP ESN поддержка -- и этого уже
достаточно чтобы меня удовлетворить. А WG хорош даже в userspace.
Это конечно не (POSIX) Make, а GNU Make. Почему это просто не сделать
shell циклом? Наверное потому что make будет распараллеливать эти
задачи. Но есть решение куда более короткое (требующее, вместо GNU Make,
GNU Parallel):
По моему гораздо проще -- всё же однострочник, вмиг набираемый в
командной строке. Автор комментария отметил что Make не может тут ничего
поделать с именами с пробелами: с parallel их не возникнет.
Аналог на redo будет такой:
all.do:
find . -name "*.bmp" -maxdepth 1 |
while read f ; do echo ${f%.bmp}.png ; done |
xargs redo-ifchange
В отличии от GNU Make не требует знания сверх shell-а, без проблем будет
работать с пробелами. Если убрать -maxdepth, то и с иерархией файлов в
директориях будет отрабатывать без проблем (в parallel аналогично можно
сделать просто указав **.bmp или направив find). "mv $3.png $3" я делаю
только потому что мне лень искать как convert-у указать формат выходного
файла, поэтому подсказываю ему расширением. all.do можно конечно и
покороче записать, если файлов не много и они без пробелов:
all.do:
redo-ifchange `for f in *.bmp ; do echo ${f%.bmp}.png ; done`
Но у этих решений есть большой недостаток: а что будет если компьютер
упадёт? Нужны sync-и и только потом удалять оригинальный .bmp. Make
оставит за собой побитый .png мусор, но так как .bmp не удалён, можно
понять что задача не была завершена.
(Корректная реализация) redo делает sync на $3 файл автоматом, как DJB и
задумывал. goredo ещё явно делает и sync на директорию после
переименования. Но тут проблема с rm-ом: он выполняется до
автоматического redo sync-а. Руками вставить sync до rm --
гарантированно сбросит содержимое PNG, но не гарантирует что файл .png
будет создан переименованием. Можно сделать промежуточную .do цель,
которая заставит сначала сделаться (redo-ifchange) .png, а потом удалит
.bmp оригинальный.
Но по хорошему я бы просто ничего не удалял во время работы -- а
подчистил после отработки всего и вся. parallel, sync, rm *.bmp. redo
будет медленнее Make для этой задачи, так как 1) на диске хранит
состояние целей и зависимостей, 2) делает sync (ok, можно отключить
зачастую) и переименования файлов.
Sergey Matveev [Tue, 1 Dec 2020 13:51:19 +0000 (16:51 +0300)]
Не хотел бы я писать под Эльбрус?
А ведь наверняка на работе именно он будет основным местом для будущих
проектов. Хотя ведь есть же и Байкалы ARM-ы и MIPS32-ы, и КОМДИВ-ы
(MIPS64), но что-то с ними не удовлетворённости у людей (конкретики не
знаю, возможно речь просто про производительность).
А с Эльбрусом пока сложно ответить на вопрос. С одной стороны: идут они
в жопу ибо даже ассемблер закрыт! Ты НЕ можешь командовать своим
процессором, ибо не знаешь его команд. Используй только закрытый
проприетарный C-компилятор lcc. С другой стороны, много статей говорит
что в x86-эмуляции он не шибко просаживается по скорости и его можно
считать просто как альтернативной x86-реализацией. Против чего я в
общем-то ничего против уже не имею. Не, я считаю что x86 уже не один
десяток лет должен быть в гробу, но раз уж даже на отечественном рынке
MIPS/ARM-ы не удовлетворительны (по производительности?), то пока
деваться уж некуда, как и дома я же x86 использую.
А ещё с одной стороны: а что значит писать под Эльбрус? Там в теории
точно такой же Debian, Java, Python. Если уж программа работает на
FreeBSD/Clang/BSDlibc и на GNU/Linux/GCC/glibc, то и на Эльбрусе
(предполагая что забываем про ассемблерные вставки) уж должно взлететь.
Знать что программа будет запускаться вместо *BSD на e2k/GNU/Linux --
мне без разницы что за платформа, код то портируемый (должен быть).
А если речь про какую-то чисто e2k-специфику, то значит помогать
использовать эту платформу, вкладываться и продвигать платформу, которая
даже не открывает ассемблер свой, не говоря про то, что без несвободного
ПО ты не сможешь на ней ничего делать.
Sergey Matveev [Tue, 1 Dec 2020 13:11:20 +0000 (16:11 +0300)]
Midnight Commander то написал Мигель де Икаса
https://habr.com/ru/company/jugru/blog/530734/
Мигеля я вроде знаю, особенно когда его Столлман отругал, по GNOME и
Mono, но что-то не замечал что MC то тоже он написал. А MC я обязательно
раз в неделю да запущу.
Ещё увидел объяснение от RMS почему Tcl всё же не взят для glue
language: https://vanderburg.org/old_pages/Tcl/war/0000.html
И с ним я тут не сильно согласен, ибо "tcl непривычен" для
пользователей... ok, а Lisp значит привычнее? Хотя в принципе есть и
верное замечание про работу с числами, но у меня сомнения так ли это
должно волновать и парить его пользователя? Но я про Tcl мало всё же
знаю, поэтому не продолжаю тему.
Sergey Matveev [Tue, 1 Dec 2020 05:36:43 +0000 (08:36 +0300)]
OpenZFS 2.0
https://github.com/openzfs/zfs/releases/tag/zfs-2.0.0
Фичи очень вкусны вошедшие в этот релиз:
* последовательный resilver -- теперь у обычного RAID вообще нет даже
крайних случаев когда он бы мог быть быстрее при rebuild-е
* persistent L2ARC -- я с L2ARC только игрался (нет задач настоящих), но
помню как неприятно было что кэш надо было прогревать после перезагрузки
* Zstandard сжатие -- вот это то, что очень хочется попробовать. Но
никакой уверенности конечно же что будет стоить этого на домашних не
сильных процессорах. Но на ноутбуке я упирался в скорость НЖМД, а не
CPU, получая сжатие сильнее чем у gzip
* send/recv redaction -- ну тут не могу оценить. Ведь грамотное
разбиение на dataset-ы же достаточно вроде как
Sergey Matveev [Tue, 1 Dec 2020 05:21:05 +0000 (08:21 +0300)]
Стенотайп
https://habr.com/ru/post/530682/
https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D0%BD%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D0%B0
Интереснейшее введение про то, что такое стенотайп. Раньше и слова то
такого не знал, но всегда было интересно видеть в американских фильмах
как на судах за маленькими устройствами на длинной ленте что-то
печатают. Теперь понятно как оно устроено. А то после фильма и забывал
посмотреть что это же это такое. 300 слов в минуту могут записывать!
Sergey Matveev [Mon, 30 Nov 2020 15:42:13 +0000 (18:42 +0300)]
Факты о Гайбраше
https://grumpygamer.com/guybrush_fact_fiction
Я кстати тоже про себя запомнил, как оказалось, миф о том, что файл имел
расширение .brush. И такое длинное расширение означало что оно делалось
не под DOS, а на Amiga.
Sergey Matveev [Mon, 30 Nov 2020 15:31:51 +0000 (18:31 +0300)]
Пример open-source, но не free software
https://blog.yossarian.net/2020/06/03/You-may-not-use-my-projects-in-a-military-or-law-enforcement-context
Вот тут автор ПО говорит что будет вставлять в свои open-source проекты
запрет на использование для военщины.
Sergey Matveev [Mon, 30 Nov 2020 08:11:13 +0000 (11:11 +0300)]
Посмотрел "Ужин с придурком"
https://ru.wikipedia.org/wiki/%D0%A3%D0%B6%D0%B8%D0%BD_%D1%81_%D0%BF%D1%80%D0%B8%D0%B4%D1%83%D1%80%D0%BA%D0%BE%D0%BC_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_1998)
Смеялся от души массу времени!
Причём главный герой ("придурок") в общем-то вызывает уважение.
Sergey Matveev [Mon, 30 Nov 2020 07:38:29 +0000 (10:38 +0300)]
Скучает по DTrace
https://utcc.utoronto.ca/~cks/space/blog/solaris/DTraceStillMiss
https://utcc.utoronto.ca/~cks/space/blog/solaris/DTraceVersusEBPF
Человек много лет проработавший с Solaris и DTrace недавно переехал на
GNU/Linux. И вот пишет что всё равно eBPF пока не такая клёвая и хорошая
замена DTrace, так как, как и в целом во всей Linux-экосистеме, в теории
всё можно делать тип-топ, а на практике всё сырое. Всё очень сильно
зависит от версий ПО, в противовес когда одна команда работает над всем
и сразу.
Sergey Matveev [Sun, 29 Nov 2020 08:54:44 +0000 (11:54 +0300)]
mpv коммит о locale
https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe
Я много где читал что POSIX locales это ужасная штука. Но сам не
сталкивался с ними, будучи программистом C. А тут вот в mpv есть коммит
объясняющий почему с ними всё так плохо. Насколько понимаю, тьму проблем
решает UTF-8.
stream_libarchive: workaround various types of locale braindeath
Fix that libarchive fails to return filenames for UTF-8/UTF-16 entries.
The reason is that it uses locales and all that garbage, and mpv does
not set a locale.
Both C locales and wchar_t are shitfucked retarded legacy braindeath. If
the C/POSIX standard committee had actually competent members, these
would have been deprecated or removed long ago. (I mean, they managed to
remove gets().) To justify this emotional outbreak potentially insulting
to unknown persons, I will write a lot of text. Those not comfortable
with toxic language should pretend this is a religious text.
C locales are supposed to be a way to support certain languages and
cultures easier. One example are character codepages. Back when UTF-8
was not invented yet, there were only 255 possible characters, which is
not enough for anything but English and some european languages. So they
decided to make the meaning of a character dependent on the current
codepage. The locale (LC_CTYPE specifically) determines what character
encoding is currently used.
Of course nowadays, this is legacy nonsense. Everything uses UTF-8 for
"char", and what doesn't is broken and terrible anyway. But the old ways
stayed with us, and the stupidity of it as well.
C locales were utterly moronic even when they were invented. The locale
(via setlocale()) is global state, and global state is not a reasonable
way to do anything. It will break libraries, or well modularized code.
(The latter would be forced to strictly guard all entrypoints set
set/restore locales, assuming a single threaded world.)
On top of that, setting a locale randomly changes the semantics of a
bunch of standard functions. If a function respects locale, you suddenly
can't rely on it to behave the same on all systems. Some behavior can
come as a surprise, and of course it will be dependent on the region of
the user (it doesn't help that most software is US-centric, and the US
locale is almost like the C locale, i.e. almost what you expect).
Idiotically, locales were not just used to define the current character
encoding, but the concept was used for a whole lot of things, like e. g.
whether numbers should use "," or "." as decimal separaror. The latter
issue is actually much worse, because it breaks basic string conversion
or parsing of numbers for the purpose of interacting with file formats
and such.
Much can be said about how retarded locales are, even beyond what I just
wrote, or will wrote below. They are so hilariously misdesigned and
insufficient, I can't even fathom how this shit was _standardized_. (In
any case, that meant everyone was forced to implement it.) Many C
functions can't even do it correctly. For example, the character set
encoding can be a multibyte encoding (not just UTF-8, but awful garbage
like Shift JIS (sometimes called SHIT JIZZ), yet functions like
toupper() can return only 1 byte. Or just take the fact that the locale
API tries to define standard paper sizes (LC_PAPER) or telephone number
formatting (LC_TELEPHONE). Who the fuck uses this, or would ever use
this?
But the badness doesn't stop here. At some point, they invented threads.
And they put absolutely no thought into how threads should interact with
locales. So they kept locales as global state. Because obviously, you
want to be able to change the semantics of basic string processing
functions _while_ they're running, right? (Any thread can call
setlocale() at any time, and it's supposed to change the locale of all
other threads.)
At this point, how the fuck are you supposed to do anything correctly?
You can't even temporarily switch the locale with setlocale(), because
it would asynchronously fuckup the other threads. All you can do is to
enforce a convention not to set anything but the C local (this is what
mpv does), or to duplicate standard functions using code that doesn't
query locale (this is what e.g. libass does, a close dependency of mpv).
Imagine they had done this for certain other things. Like errno, with
all the brokenness of the locale API. This simply wouldn't have worked,
shit would just have been too broken. So they didn't. But locales give a
delicious sweet spot of brokenness, where things are broken enough to
cause neverending pain, but not broken enough that enough effort would
have spent to fix it completely.
On that note, standard C11 actually can't stringify an error value. It
does define strerror(), but it's not thread safe, even though C11
supports threads. The idiots could just have defined it to be thread
safe. Even if your libc is horrible enough that it can't return string
literals, it could just just some thread local buffer. Because C11 does
define thread local variables. But hey, why care about details, if you
can just create a shitty standard?
(POSIX defines strerror_r(), which "solves" this problem, while still
not making strerror() thread safe.)
Anyway, back to threads. The interaction of locales and threads makes no
sense. Why would you make locales process global? Who even wanted it to
work this way? Who decided that it should keep working this way, despite
being so broken (and certainly causing implementation difficulties in
libc)? Was it just a fucked up psychopath?
Several decades later, the moronic standard committees noticed that this
was (still is) kind of a bad situation. Instead of fixing the situation,
they added more garbage on top of it. (Probably for the sake of
"compatibility"). Now there is a set of new functions, which allow you
to override the locale for the current thread. This means you can
temporarily override and restore the local on all entrypoints of your
code (like you could with setlocale(), before threads were invented).
And of course not all operating systems or libcs implement this. For
example, I'm pretty sure Microsoft doesn't. (Microsoft got to fuck it up
as usual, and only provides _configthreadlocale(). This is shitfucked on
its own, because it's GLOBAL STATE to configure that GLOBAL STATE should
not be GLOBAL STATE, i.e. completely broken garbage, because it requires
agreement over all modules/libraries what behavior should be used. I
mean, sure, makign setlocale() affect only the current thread would have
been the reasonable behavior. Making this behavior configurable isn't,
because you can't rely on what behavior is active.)
POSIX showed some minor decency by at least introducing some variations
of standard functions, which have a locale argument (e.g. toupper_l()).
You just pass the locale which you want to be used, and don't have to do
the set locale/call function/restore locale nonense. But OF COURSE they
fucked this up too. In no less than 2 ways:
- There is no statically available handle for the C locale, so you have
to initialize and store it somewhere, which makes it harder to make
utility functions safe, that call locale-affected standard functions
and expect C semantics. The easy solution, using pthread_once() and a
global variable with the created locale, will not be easily accepted
by pedantic assholes, because they'll worry about allocation failure,
or leaking the locale when using this in library code (and then
unloading the library). Or you could have complicated library
init/uninit functions, which bring a big load of their own mess.
Same for automagic DLL constructors/destructors.
- Not all functions have a variant that takes a locale argument, and
they missed even some important ones, like snprintf() or strtod() WHAT
THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT
THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK
I would like to know why it took so long to standardize a half-assed
solution, that, apart from being conceptually half-assed, is even
incomplete and insufficient. The obvious way to fix this would have
been:
- deprecate the entire locale API and their use, and make it a NOP
- make UTF-8 the standard character type
- make the C locale behavior the default
- add new APIs that explicitly take locale objects
- provide an emulation layer, that can be used to transparently build
legacy code without breaking them
But this wouldn't have been "compatible", and the apparently incompetent
standard committees would have never accepted this. As if anyone
actually used this legacy garbage, except other legacy garbage. Oh yeah,
and let's care a lot about legacy compatibility, and let's not care at
all about modern code that either has to suffer from this, or subtly
breaks when the wrong locales are active.
Last but not least, the UTF-8 locale name is apparently not even
standardized. At the moment I'm trying to use "C.UTF-8", which is
apparently glibc _and_ Debian specific. Got to use every opportunity to
make correct usage of UTF-8 harder. What luck that this commit is only
for some optional relatively obscure mpv feature.
Why is the C locale not UTF-8? Why did POSIX not standardize an UTF-8
locale? Well, according to something I heard a few years ago, they're
considering disallowing UTF-8 as locale, because UTF-8 would violate
certain ivnariants expected by C or POSIX. (But I'm not sure if I
remember this correctly - probably better not to rage about it.)
Now, on to libarchive.
libarchive intentionally uses the locale API and all the broken crap
around it to "convert" UTF-8 or UTF-16 (as contained in reasonably sane
archive formats) to "char*". This is a good start!
Since glibc does not think that the C locale uses UTF-8, this fails for
mpv. So trying to use archive_entry_pathname() to get the archive entry
name fails if the name contains non-ASCII characters.
Maybe use archive_entry_pathname_utf8()? Surely that should return
UTF-8, since its name seems to indicate that it returns UTF-8. But of
fucking course it doesn't! libarchive's horribly convoluted code (that
is full of locale API usage and other legacy shit, as well as ifdefs and
OS specific code, including Windows and fucking Cygwin) somehow fucks up
and fails if the locale is not set to UTF-8. I made a PR fixing this in
libarchive almost 2 years ago, but it was ignored.
So, would archive_entry_pathname_w() as fallback work? No, why would it?
Of course this _also_ involves shitfucked code that calls shitfucked
standard functions (or OS specific ifdeffed shitfuck). The truth is that
at least glibc changes the meaning of wchar_t depending on the locale.
Unlike most people think, wchar_t is not standardized to be an UTF
variant (or even unicode) - it's an encoding that uses basic units that
can be larger than 8 bit. It's an implementation defined thing. Windows
defines it to 2 bytes and UTF-16, and glibc defines it to 4 bytes and
UTF-32, but only if an UTF-8 locale is set (apparently).
Yes. Every libarchive function dealing with strings has 3 variants:
plain, _utf8, and _w. And none of these work if the locale is not set.
I cannot fathom why they even have a wchar_t variant, because it's
redundant and fucking useless for any modern code.
Writing a UTF-16 to UTF-8 conversion routine is maybe 3 pages of code,
or a few lines if you use iconv. But libarchive uses all this glorious
bullshit, and ends up with 3 not working API functions, and with over
4000 lines of its own string abstraction code with gratuitous amounts of
ifdefs and OS dependent code that breaks in a fairly common use case.
So what we do is:
- Use the idiotic POSIX 2008 API (uselocale() etc.) (Too bad for users
who try to build this on a system that doesn't have these - hopefully
none are left in 2017. But if there are, torturing them with obscure
build errors is probably justified. Might be bad for Windows though,
which is a very popular platform except on phones.)
- Use the "C.UTF-8" locale, which is probably not 100% standards
compliant, but works on my system, so it's fine.
- Guard every libarchive call with uselocale() + restoring the locale.
- Be lazy and skip some libarchive calls. Look forward to the unlikely
and astonishingly stupid bugs this could produce.
We could also just set a C UTF-8 local in main (since that would have no
known negative effects on the rest of the code), but this won't work for
libmpv.
We assume that uselocale() never fails. In an unexplainable stroke of
luck, POSIX made the semantics of uselocale() nice enough that user code
can fail failures without introducing crash or security bugs, even if
there should be an implementation fucked up enough where it's actually
possible that uselocale() fails even with valid input.
With all this shitty ugliness added, it finally works, without fucking
up other parts of the player. This is still less bad than that time when
libquivi fucked up OpenGL rendering, because calling a libquvi function
would load some proxy abstraction library, which in turn loaded a KDE
plugin (even if KDE was not used), which in turn called setlocale()
because Qt does this, and consequently made the mpv GLSL shader
generation code emit "," instead of "." for numbers, and of course only
for users who had that KDE plugin installed, and lived in a part of the
world where "." is not used as decimal separator.
All in all, I believe this proves that software developers as a whole
and as a culture produce worse results than drug addicted butt fucked
monkeys randomly hacking on typewriters while inhaling the fumes of a
radioactive dumpster fire fueled by chinese platsic toys for children
and Elton John/Justin Bieber crossover CDs for all eternity.
Sergey Matveev [Sat, 28 Nov 2020 08:30:16 +0000 (11:30 +0300)]
Настоящие трусливые подлые террористы
https://lenta.ru/news/2020/11/28/bhy/
https://lenta.ru/news/2020/11/19/austr_afgh/
То США просто так убило КСИРовца в Ираке в начале года (потом им
отомстили), то была речь "а не убить ли Асада?", теперь вот в Афганстане
уже другие англосаксы показывают свою суть, израиль вот засветился
подлым и трусливым убийством. Ещё раз убеждаюсь что Западный мир
(ангосаксы, евреи) это террористы номер один в мире, не говоря про
коварные и подлые бесчестные игры, подстрекательства и кучу лжи.
Sergey Matveev [Fri, 27 Nov 2020 15:23:59 +0000 (18:23 +0300)]
NoJS club
https://nojs.club/
Чтобы "вступить" в клуб, нужно отправить issue на Github... на котором
без JS не зарегистрироваться, насколько знаю (возможно какие-то действия
через внешние инструменты можно проделать).
Sergey Matveev [Fri, 27 Nov 2020 13:00:51 +0000 (16:00 +0300)]
Google CAPTCHA доказывают что ты американец, а не человек
https://shkspr.mobi/blog/2017/11/captchas-dont-prove-youre-human-they-prove-youre-american/
Вот-вот! Всё же мне приходилось натыкаться на CAPTCHA и я не раз
удивлялся некоторым "вопросам" которые явно мне чужды и я могу ответить
на них только по фильмам пиндосским. Там в комментариях и говорят про
примеры идиотизма.
Sergey Matveev [Fri, 27 Nov 2020 10:26:14 +0000 (13:26 +0300)]
В Python 3.8 предлагают использовать pax формат архива по умолчанию
https://bugs.python.org/issue36268
Кроме того, что сам GNU Tar не рекомендует GNU Tar, а pax, кроме того
что NetBSD/OpenBSD не поддерживают GNU Tar:
* For C/C++, Libarchive and GNU tar are the modern two heavy hitters,
and they both have supported it for a very long long. Modern version
of old-style bsdtar should, but if not then they don't support GNU tar
either. These are commonly used when needed with C/C++, or programmers
implement their own bespoke solutions.
* Libtar (C) does not, but it hasn't been updated for 6 years (and has
been in minimal maintenance mode for over 15) so I'm not sure its
really relevant anymore. Virtually any platform will also have one of
the previous.
* The major implementation for Java, Apache Commons Compress, added
support for both pax and GNU in its 1.2 version, back in 2011 (8 years
ago)
* R uses the system's tar executable (or bundled modern tar), so will
have the same support as that (i.e. any remotely modern system should
be compatible). Their documentation explicitly recommends against GNU
tar in favor of pax or ustar instead for portability:
https://stat.ethz.ch/R-manual/R-devel/library/utils/html/tar.html
* git-archive uses pax exclusively
* PHP supports ustar only, not pax or GNU; in that case pax is generally
the more compatible of the two extended formats
* The node-tar library, the apparent standard for Javascript, support it
* The standard tar package for Go supports it
* What seems to be the major current implementation for C#, SharpZipLib,
supports it
* Ruby has no apparent standard implementation; a few third-party
libraries have a mix of support
Sergey Matveev [Thu, 26 Nov 2020 20:26:22 +0000 (23:26 +0300)]
Greg Kroah-Hartman использует Filco клавиатуры и трэкбол
https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroahhartman_linux_kernel_developer_ama/
Бесполезный факт, но здорово, что настоящие профи программисты все как
один за тактильными клавиатурами. И трэкболы очень в ходу.
https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroahhartman_linux_kernel_developer_ama/cmi2khj/
А ещё ему больше нравится Go, чем Rust.
Узнал про "WET" (Write Everything Twice), не слышал прежде. А вот DRY я
сам постоянно использую слово.
Sergey Matveev [Thu, 26 Nov 2020 15:57:07 +0000 (18:57 +0300)]
Впервые начал генерировать .do другим .do
Для тестов нужны данные из ASN.1 структуры. Достать их можно по
длине/смещению, которые можно узнать распарсив бинарь. Но для парсинга
нужен Python, PyDERASN. Не заставлять же их ставить. Поэтому .do.do файл
является исполняемым, с Python shebang-ом, который выплёвывает dd
строчку с нужными seek/count параметрами. Уж такую мелочь для
неизменного входного файла можно и закоммитить.
Sergey Matveev [Thu, 26 Nov 2020 09:29:23 +0000 (12:29 +0300)]
Github сделает тёмную тему
https://habr.com/ru/news/t/529996/
Вот он современный web во всей красе! Вместо того, чтобы выдавать
нормальную структурированную информацию (HTML просто) и каждый сам бы
себе настраивал как *ему* хочется чтобы всё отображалось, все будут
терпеть и ныть 7 лет. У меня в броузере Xombrero даже из коробки можно
нажать кнопочку "s" и цвета будут что-то типа инвертированы (точнее
какой-то CSS применяется, не вдавался в подробности) и всё ставится
тёмным и красивым. А "S" глобально это включает, чтобы мне на каждую
страницу не надо было жать "s".
Sergey Matveev [Wed, 25 Nov 2020 21:53:23 +0000 (00:53 +0300)]
Интереснейшая история Фортран, Алгол, Ада, Паскаль
https://habr.com/ru/company/dataart/blog/529916/
Андрей Терехов (завкафедрой системного программирования Матмеха СПбГУ,
профессор, доктор физмат наук) рассказывает о том как в СССР проникали
всякие зарубежные языки.
Sergey Matveev [Tue, 24 Nov 2020 21:40:30 +0000 (00:40 +0300)]
Как находятся баги? KRACK
https://cryptologie.net/article/511/how-do-people-find-bugs/
https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/
Интересная подборка того, что даже в формально верифицированных
протоколах всё равно могут быть ошибки и несостыковки. Ох уж эти люди...
In modern world, bugs find you.
I don't find bugs -- I write them.
А вторая статья про KRACK атаку на 802.11i. Мэтью Грин так лестно
отзывается об IEEE! И по сути это их огромный fail что такое кривое
получается в плане безопасности.
Sergey Matveev [Tue, 24 Nov 2020 17:43:16 +0000 (20:43 +0300)]
Свой CA
В Паутине тьма примеров как сваять свой CA на основе OpenSSL команд. Я
считаю OpenSSL команды чистым садизмом и издевательством над человеком.
Как и код их библиотеки и документации. Привожу пример как можно сделать
свой CA на certtool из GnuTLS-а:
Этого достаточно чтобы софт с выпущенными сертификатами работал. Почему
ECC (ECDSA)? Потому что компактно, быстро, эффективно. На помойку тех
кто умеет только RSA. Я бы конечно предпочёл EdDSA, но это точно далеко
не всеми поддерживается.
Sergey Matveev [Tue, 24 Nov 2020 17:22:43 +0000 (20:22 +0300)]
Бесплатных то CA сколько развелось!
https://habr.com/ru/company/globalsign/blog/529698/
https://scotthelme.co.uk/introducing-another-free-ca-as-an-alternative-to-lets-encrypt/
https://docs.https.dev/list-of-acme-servers
Только ни одного вне США. ZeroSSL написали что австрийский, но он не
корневой CA, а подписан пиндосами, да и даже свой сайт у него за
Cloudflare. Активно выпиливали все зарубежные, теперь плодят своих, мол
выбор и альтернатива.
Sergey Matveev [Tue, 24 Nov 2020 09:02:57 +0000 (12:02 +0300)]
mpv и SDL
С предыдущего поста ради интереса попробовал всё же новую версию с SDL
звуком собрать. Управлять выходным устройством не нашёл как, но можно
делать sysctl hw.snd.default_unit и глобально его менять для всей
системы. Для моих задач это подходит, ибо я или только музыку слушаю,
или только на монитор звук вывожу или, лёжа на диване, вывожу в колонки
ноутбука. Обновляться не собираюсь, но в принципе жить можно. Хотя и
появляется абсолютно ненужная прослойка в виде SDL, но вроде это не
плохой софт, даже быстро собирается.
Sergey Matveev [Tue, 24 Nov 2020 08:13:10 +0000 (11:13 +0300)]
mpv и OSS/sndio поддержка
https://github.com/mpv-player/mpv/commit/71d218eae4b4d93ada34ff74906f71ad359c84bc
https://github.com/mpv-player/mpv/issues/8296
С выходом нового релиза mpv, в котором уже давно
(ed22279730f95d93e57f140807f664ba2bbbaa92) выпилили две единственные
нормальные звуковые системы. Люди начали отписываться, мол, верните. Ну
посмотрим что из этого выйдет или всё же кто-нибудь найдётся кто вернёт
их снова. Linux экосистема уже давно стала не сильно отличаться от
Windows (сложностью, непонятностью, дерьмовостью, архитектурой абсолютно
чуждой хакерской и Unix-way), а теперь ещё вот в который раз видно что
люди в ней считают что никого в округе больше нет (как и Windows
когда-то всегда считал). Причём в самом Linux как нету ничего близкого к
OSS/sndio, так и нет, но страдают теперь все пользователи mpv. Их право
конечно, они никому ничего не должны, а я как программист тоже понимаю
как сложно бывает поддерживать сильно разношёрстные вещи. Пока сижу вот
на каком-то там коммите mpv. В принципе то всё устраивает полностью.
Ведь даже mplayer мнооого лет вообще не обновляется и мне его тоже
хватало, только обновляй всякие libav/ffmpeg.
Sergey Matveev [Mon, 23 Nov 2020 19:14:43 +0000 (22:14 +0300)]
Little Big Aventures в ScummVM!
https://www.scummvm.org/news/20201122/
ScummVM снова (вслед за 592c8e4c08c63dae747cae59d46603240c1b8109)
умудряется приятно удивлять и они добавляют TwinEngine, позволяющий в
легендарные LBA поиграть! Я какое-то и прохождение смотрел и начитан про
LBA много, но играть в него так и не вышло: похоже я совсем в аркады не
умеют -- в лучшем своём прохождении я только смог выбраться из тюрьмы, в
самом начале игры, а дальше всё убивают и убивают. В прохождениях видел
что прыткость и реакция это всё что надо. Но, хоть в FPS-ах у меня было
очень неплохо всегда, а тут не получалось.
Sergey Matveev [Mon, 23 Nov 2020 13:27:36 +0000 (16:27 +0300)]
Мой Atom блога теперь отдаёт HTML
Раньше был <content type="text">, но его "\n" автоматически
escape-ились и это похоже никто не поддерживал. Сам я про эту проблему
знал, но всё откладывал, а потом и просто забыл. Сейчас делаю
type="html" с текстом обёрнутым в <pre>. В newsboat и
rss2email+mutt+lynx вроде всё показывает теперь корректно. А ещё в RFC
обратил внимание что type="text" вообще MAY быть при показе
отформатирован как угодно, забив на все whitespace-ы и переводы строк.
Так что изначально type="text" было некорректным решением.
Sergey Matveev [Mon, 23 Nov 2020 12:33:33 +0000 (15:33 +0300)]
А Вернер Кох любит HTML почту
https://lists.gnupg.org/pipermail/gnupg-users/2020-November/064364.html
... потому что простое procmail правило избавляет его от спама! :-)
Он и раньше был трушным: e86a4dc7dc0311d5da5916ea5adeb777b50d96a7 но
сейчас совсем крут. А ведь стоит, пускай не удалять, но в spam помещать
всё где HTML! Иногда всё же умудряются находится люди которые шлют в HTML.
Sergey Matveev [Mon, 23 Nov 2020 09:51:06 +0000 (12:51 +0300)]
Посмотрел "Полуночную жару"
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D1%83%D0%BD%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D0%B6%D0%B0%D1%80%D0%B0_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_1967)
Отличный фильм! Но я оказывается уже слушал радиоспектакль по книге по
которой снят этот фильм. Так что о сюжете уже в курсе.
Sergey Matveev [Sun, 22 Nov 2020 17:26:05 +0000 (20:26 +0300)]
Ускорение запуска bash
https://work.lisk.in/2020/11/20/even-faster-bash-startup.html
Не только я обеспокоен задержками при запуске базовых простых вещей,
типа калькулятора. Помню что тоже мерил и zsh и vim время запуска всяких
штук, оптимизируя.
Sergey Matveev [Sun, 22 Nov 2020 15:55:12 +0000 (18:55 +0300)]
Каганов заценил современный русский хип-хоп
http://lleo.me/dnevnik/2020/11/22_1
Моргенштерн, Элджей, Макс Корж, Егор Крид:
* это всё попса, а не хип-хоп
* раскрутка искусственным шумом
* петь не умеют, слова... без комментариев
Sergey Matveev [Sun, 22 Nov 2020 15:27:18 +0000 (18:27 +0300)]
Фишки современных эмуляторов терминала
https://www.youtube.com/watch?v=9DgQqDnYNyQ
* Unicode/UTF-8. Ими в видео показывают как отображают прям иконки
директорий например. Ну тут вопрос шрифтов только, по моему. Выглядит
интересно, но по сути даже в примере видео я ориентируюсь по цвету --
ну никто же не будет вглядываться в иконку
* Лигатуры -- тоже вопрос шрифтов. Кому-то нужны/нравятся
* SGR ANSI коды. Ну вот это точно может ощутимо помогать визуально.
st поддерживает конечно же
* Поддержка мыши -- а вот это абсолютное зло! Готов крушить и громить
когда я не могу выделить кусок текста, ибо какая-то сраная программа
перехватываешь мышь. Нафиг мне терминал если я не могу выделить в нём
что-то или вставить? st кстати поддерживает проброс мышки
* OSC коды -- общение с буфером обмена, выставлением title-ов окон. Да,
это must-have. st конечно же держит. Для lynx даже писал патч чтобы он
выставлял название окна/сайта. В vim это тоже нужно выставлять чтобы и
в tmux показывалось нормальное название tab-а
* bracketed paste mode -- если этого нет, то терминал просто неюзабелен.
Но меня удивляет как мало людей знает про эту штуку, насилуя себя
какой-нибудь ручной работой с set paste в Vim
* 24-бит цвет. Боюсь что подобное я даже отключаю, например в Vim. Ибо
мне нужны хорошие сочные яркие цвета. default цветовые схемы на 24-бит
-- блёклые. st поддерживает
* поддержка отображения bitmap графики (Sixel). Вот это st не держит, да
и вообще не много кто. Под вопросом насколько это удобно, но что-то не
слышал чтобы люди особо это использовали. Ну и тут много разных
несовместимых реализаций и плохая совместимость с другим софтом. Но
даже в видео у человека ооооочень медленно отображаются картинки, что
для меня точно было бы не юзабельно
Как минимум не сказали про то как мышкой, разными кликами, можно
выделять слова или предложения. А ещё всякий XIM ввод (хотя я этим
никогда не пользовался). А ещё некоторые позволяют производить какие-то
действия над выделенным текстом.
Sergey Matveev [Sun, 22 Nov 2020 15:22:51 +0000 (18:22 +0300)]
Снова Туктамышева крута
https://www.championat.com/figureskating/article-4195009-figurnoe-katanie-gran-pri-2020-2021-proizvolnaja-programma-zhenschiny-muzhchiny-onlajn-transljacija-21-nojabrja-2020.html
Оказывается уже как два года (9b57fe2c57650546ae8b55de278cda720a92d6f4)
я если и вижу упоминание Туктамышевой, то обязательно зайду в новость
посмотреть на фотографии с ней. Посмотрел на других в этой статье: ну
посмотрел и посмотрел. А вот Туктамышевой налюбоваться не могу.
Sergey Matveev [Sun, 22 Nov 2020 15:10:38 +0000 (18:10 +0300)]
Посмотрел "Не/смотря ни на что"
https://ru.wikipedia.org/wiki/%D0%9D%D0%B5/%D1%81%D0%BC%D0%BE%D1%82%D1%80%D1%8F_%D0%BD%D0%B8_%D0%BD%D0%B0_%D1%87%D1%82%D0%BE
Местами ускорял просмотр, ближе к концу, но фильм понравился. Хотя в
целом я и не одобряю главного героя что он на такой важной работе врал и
не говорил о слепоте. Ну да, смог достичь и даже в таком состоянии
успехов, но ведь это же и заслуга кто ему помогал. Это же просто тупо
опасно для жизни и своей и окружающих. Как и героиня с ребёнком тоже
сказала ему в лицо что доверила своего ребёнка тому, кто точно не мог бы
за ним приглядывать. Да, если бы он говорил о своём состоянии, то работы
ему не видать. Только если бы он не представлял опасности для себя и
окружающих (а покалечив себя, работодателю придётся несладко), то я бы
промолчал, мол ложь во благо.
Sergey Matveev [Sun, 22 Nov 2020 12:50:00 +0000 (15:50 +0300)]
Снова доработки goredo, redo-stamp и хэширование
Вчера обнаружил что при REDO_NO_HASH на самом деле не работает
redo-stamp поведение. Ничего не падает, но цель остаётся изменённой,
даже если stamp остаётся прежним.
Сам по себе redo-stamp у меня был некрасивым хаком: если во время
определения OOD (out-of-date) цели мы понимаем что она со штампом, то в
конце, если она требует пересборки, запускаем выполнение этой цели,
прямо внутри OOD функции, рекурсивно вызываемой. Это мешало
распараллеливанию -- одна проблема. По сути я делал изменение порядка
выполнения целей и зависящие штампа (а это так или иначе связанные с
redo-always целями), выполняя их раньше, а дальше, благодаря хэшам (на
штампам!), остальные считали что цель не изменилась.
Отключение хэшей приводит к тому, что цели всё равно, не смотря на штамп
пересобираются, ведь ctime то поменялся. А алгоритм понимания OOD цели
взят из redo-c и предельно прост: прочитать .dep, пройтись по каждой
записи в нём, если она имеет .dep, то рекурсивно вызвать OOD на неё.
Просто "сверху вниз" идём и смотрим не устарел ли кто. С отключением
хэшей приходится из-за штампов *заранее* понимать является ли цель
-always или -stamp, а также добавлять состояние о том что в *текущей*
сборке штамп не изменился. Это в итоге у меня заработало, есть коммит,
но это сущий ад уродства и хака, когда мы не просто спускаемся, а
заранее читаем и узнаём про зависимость. Плюс я ещё не добавлял
распараллеливание выполнения out-of-order always/stamped целей (так как,
скорее всего, такие цели на практике будут лёгкими (определение
переменных окружения, версии какой-нибудь), то это не создаёт проблем.
Но в общем случае оно страшно.
Если что-то всё слишком усложняется и добавляется хак то тут, то там
(например просасывание текущего stamp чтобы понять, в момент вызова
redo-stamp, остался ли он прежним), то что-то делается не так. Моя не
работающая версия с redo-stamp по сути делала только одно, давая нужное
и ожидаемое на самом деле поведение (поэтому я был уверен что оно
работало) -- меняла порядок выполнения целей, а дальше хэши делали
нужное поведение.
А не хотелось бы пользователю прописать redo-stamp в каждой цели? В
идеале хотелось бы, поэтому redo-stamp выглядит полнейшим уродством.
Теперь я яростно против него, видя как он на самом деле всё усложняет.
А что говорит apenwarr?
https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps
Могут быть проблемы с пустыми файлами. Так как их хэши всегда остаются
прежними и цель будет считаться всегда свежей. Это единственный аргумент
который я принимаю... в общем случае, если бы не тот факт, что и redo-c
и apenwarr/do и apenwarr/redo и goredo при отсутствии stdout выхлопа не
создают файл, а отсутствие файла является признаком всегда протухшей
цели. На практике из-за этого нет никаких проблем и с желанием делать
пустые файлы, которые не устаревают (например создание какого-нибудь .rc
в котором реально нет никаких команд, выставляющих флаги), и с желанием
делать псевдо-цели "агрегаты". Если есть желание не делать выхлоп, но
всё равно иметь stamp -- ну так сделать запись в файл какого-нибудь хэша
от нужных данных, а файл не использовать. "Родное" хэширование
(go)redo(-c) из-за малого объёма данных будет супер лёгким. Поэтому на
практике это не проблема, повторюсь. Но она требует полноценной
поддержки и работы с stdout захватом и $3 файлом, чего некоторые
реализации не делают, считая захват stdout вредом. Ну вот и получается:
если забить на оригинальное предложение DJB с stdout/$3 -- имеем кучу
проблем и негибкостей, например при постоянной проверке хэшей. Сами
дураки что отказались -- сами же себе создали проблем. Те кто создают
пустые файлы при отсутствии stdout (я уверен что автор redo-c плохо
подумал, влив чей-то глупый pull request в последних коммитах) -- сами
же себе создали невозможность создания агрегатов и постоянно протухающих
целей. Короче, DJB всё предложил как никогда правильно и корректно!
Что ещё apenwarr говорит на тему "почему бы не всегда делать хэши?"
* It makes it hard to force things to rebuild -- просто touch-ем
действительно не выйдет. Но есть redo (не -ifchange, который по
умолчанию делает force)
* Targets that are just used for aggregation -- это снова пустые файлы.
С ними нет проблем, так как они будут отсутствовать
* Calculating checksums for every output file adds time to the build --
учитывая скорость современных быстрых хэшей (BLAKE2/3, Skein), даже
просто на современных файловых системах всегда все данные хэшируются
(ZFS). В теории оно конечно добавляется время, так как оно в любом
случае что-то делает/занимает на CPU, но так ли это увеличивает время,
чтобы жертвовать простотой софта и удобством пользователя не заставляя
его писать каждый раз и думать где нужен redo-stamp? Сколько времени
будет сэкономлено потому что он не поставил redo-stamp, а выполнение
какой-нибудь сверх лёгкой цели типа "echo ${GO:-go}" займёт ГОРАЗДО
больше времени, так как нужно запустить дочерний sh процесс. Я убеждён
что на практике это совсем не аргумент. Ну и речь же не про абсолютно
всегда проверку хэша, а если, например, только ctime поменялся --
поэтому если на диске будет лежать гигабайтный tarball, который просто
лежит, то хэшироваться он не будет при проверке OOD
* Building stuff unnecessarily and then stamping it is much slower than
just not building it in the first place, so for almost every use of
redo-stamp -- не понял к чему, ведь как-раз stamp-ы наоборот позволяют
не собирать unnecessarily. Или это к тому, что проще собрать "echo
${GO:-go}" чем проверять хэш? Возможно только если процесс хэширования
очень медленный, что не правда на практике
* To steal a line from the Zen of Python: explicit is better than
implicit. Making people think about when they're using the stamp
feature. -- Нет уж, снова не согласен и автор противоречит себе.
Почему же ifcreate/ifchange implicitly ставятся? А как же Zen?
Потому что это точно удобно будет всем, оно уменьшает нагрузку на
пользователя, помогает ему (а инструмент должен помогать!). Checksum-ы
и желание делать redo-stamp абсолютно всегда, если создаётся $3 --
абсолютно нормально и адекватно
* djb's (as yet unreleased) version of redo doesn't implement checksums
а вот это не правда, ибо я сам помню что речь про checksum-ы я видел в
его статьях. Там речь вообще только про них и была, никаких
ctime/mtime/whatever
Как с самого начала мне не нравились ВСЕ аргументы apenwarr, так сейчас
и подавно. Сейчас на практике я вижу НАСКОЛЬКО это всё усложняет и
уродует. Проблем с aggregation targets и пустыми файлами нет, если не
забивать на stdout и не создавать пустые файлы когда пользователь это
явно не попросил (touch $3). Мне кажется, apenwarr/redo просто борется с
тем, что в Python это всё медленно, хоть сами хэши и на C, но
просасывать данные нужно через Python.
Поэтому я решил выпилить возможность отключения хэшей и выпилил всё
уродство с redo-stamp. Сама команда и даже запись в .dep остались, но
ни на что не влияют. Однако порядок выполнения целей теперь хаотичен,
как и был и как и должен был быть. И проблема в том, что определение OOD
целей, множества целей, может происходить задолго до того как
always цель выполнится. Если поставить маленький уровень параллелизма,
неспешно рассматривая OOD каждой задачи и выполняя их, то всё неплохо. В
противном случае, всё работает, но много целей будут выполнятся потому
что OOD решил что они протухли, ибо always цель ещё не выполнилась. В
общем, проблема (чтобы всё красиво работало: например видя изменение
пути к AR команде, только .a пересобрался, а другие даже не пытались бы)
только с порядком выполнения зависимостей. И проблема и вся эта головная
боль только и только при наличии redo-always зависимостей, что даже
чисто теоретически говорит что раз always, значит протухший всегда,
значит все кто от тебя зависят -- тоже автоматом протухшие, всё честно.
И если следовать принципу apenwarr -- уже лучше пересобрать, чем что-то
недособрать, то можно и вообще ничего не делать.
Но я решил всё же хоть как-то но побороть и оптимизировать это всё.
Сначала я нахожу все always зависимости, попутно полностью собирая
информацию о том как кто на кого влияет. В любом случае. .dep файлы мы и
так читаем, поэтому тут overhead на ОС/диск не увеличиваются, ну кроме
как на чтение из кэша. Затем явно параллельно выполняю их. То есть
форсирую выполнение always раньше всего остального. А дальше я собираю
параллельно все цели которые зависят от каждого always. Затем выполняю
тех кто зависят от них. И продолжаю пока не будет ни одной задачи
протухшей. Звучит как ресурсоёмко, как плохо распараллеливаемо, как то,
что мы идём в обратном направлении по дереву зависимостей (а так и
есть), но на практике все case-ы которые я могу придумать, при
использовании always -- очень быстро должны сходится на нет (у меня во
всех проектах так и есть), если always не изменился. А дальше
запускаются штатные сборки, если, конечно же, они всё же OOD.
Пришлось добавить много кода. Но он касается чисто определения порядка
выполнения целей, без уродств. Если always целей нет, то всё работает
чисто по старинке, максимально просто и тупо как в redo-c. Даже не
смотря на "много" кода -- кол-во добавленных строчек чуть-чуть стало
больше чем я выпилил stamp-specific кода! При этом весь новый код
сосредоточен только в ifchange алгоритме/работе, не затрагивая
OOD/runScript функции.
Sergey Matveev [Sat, 21 Nov 2020 17:11:40 +0000 (20:11 +0300)]
Доработки goredo
http://www.goredo.cypherpunks.ru/
Jobserver, аналогичный своей сутью на GNU Make-овый, я добавил в goredo
под конец. Ну и конечно же после этого обнаружил что при кол-ве задач 1
оно бывает виснет. --debug показывает что возникает где-то deadlock. Без
ограничения кол-ва задач всё работает. Потратил много часов, но проблема
оказалась в двух строчках defer-ов, помененных местами: было ожидание
завершение задач, но которые не могли продолжить работу, так как мы свой
job-токен ещё не отдали.
Плюс оптимизации производительности определения свежести цели и redo-dot
утилита, которая сгенерирует DOT зависимостей. На практике, в моём
проекте из-за большого количества взаимосвязей она не знаю для чего
могла бы пригодится, но, опять же, сделать так легко, а надо же догнать
и перегнать альтернативные реализации.
Sergey Matveev [Fri, 20 Nov 2020 18:01:27 +0000 (21:01 +0300)]
Boost индукционной плиты
Тётя мне показала что можно одним нажатием на кнопку "boost" ощутимо
добавить мощности нагрева индукционной плиты. Она и так значительно
быстрее вскипятит воду чем электрический чайник, а с boost-ом вообще
чудеса. Кнопку видел, но даже не задумывался что это и для чего, хотя
она и говорит сама за себя.
Sergey Matveev [Fri, 20 Nov 2020 16:40:50 +0000 (19:40 +0300)]
I redo redo
http://git.cypherpunks.ru/cgit.cgi/goredo.git/tree/README
Психанул и написал свою redo реализацию на Go!
Python apenwarr/redo всем хорош, но Python зависимость не очень приятна.
Плюс при большом уровне параллелизма у него иногда что-то сбоит и он
падает. Не критично, ибо всё равно потом всё недособранное можно
пересобрать (это ж не Make, где с чистого листа только безопасно будет),
но не приятно.
redo-c не имеет redo-stamp команды. С ней просто приятнее и удобнее
жить. Плюс он не уважает umask, ибо просто используется mkstemp(). И
мозолят глаза его .dep. файлы в каждой директории.
Решил было просто переписать его на Go. И в основу он полностью и лёг.
Но на Go так приятно и легко пишется, что я по сути почти все фичи
apenwarr/redo реализации засунул. Ровно один день чтобы написать рабочую
(текущие проекты полностью мочь без проблем *пере*собирать) redo
реализацию. Тестами ничего не покрыто, но у себя всё что в голову
приходило и на нетривиальном проекте с default/redo-stamp разнообразием
оно отрабатывает идеально. Сейчас я даже Python реализацию удалил из
путей.
Что добавил, чего не было в redo-c:
* всегда захватывать stdout. Как и в apenwarr/redo, явно проверяется не
записал ли пользователь И в stdout И в $3. Я не раз по неосторожности
так делал и это сильно помогало
* явно проверять что собранный файл не изменился пользователем, вне
контекста сборки redo, опять же, как это делает apenwarr/redo -- это
очень удобно, ибо позволяет временно вносить правки и смотреть что
получится, но файлы не будут перезатёрты
* исполняемые файлы запускаются как есть, содержащие shebang --
запускаются с ним. Ну а оставшиеся с /bin/sh -e (или -x в дополнении)
* redo -x покажет trace (sh -x) только для текущих указанных целей, а не
всех -- оказалось это очень удобно (но можно через env выставить и
показ вообще всего для всех)
* уважение umask
* redo-stamp, redo-whichdo (мне не надо, но сделать легко)
* в .dep файле сохраняется и UUID сборки, по которому можно понять а
была ли цель уже собрана, ведь от неё могут зависеть многие, а на ней
стоит redo-always или redo-stamp какой-нибудь. Позволяет избежать
возможных повторных ненужных сборок. В apenwarr/redo тоже хранится
информация о конкретной сборки, поэтому в нём тоже избежали эту
проблему
* lock-и и зависимости для каждой цели у меня аналогично в отдельных
файлах, но все они собраны в .redo поддиректории (каждой директории
проекта), что просто разгружает глаз. Там же хранятся и .log файлы
А теперь отличия от навороченного apenwarr/redo:
* apenwarr/redo проверяет размеры, mtime и ещё несколько параметров
файла для определения его свежести. Насколько понимаю, ctime он не
использует потому что он меняется с изменением link count-а. Я
использовал подход redo-c: проверка ctime, если не совпал, то проверка
хэша файла. Проверка хэша убирает false positive срабатывание. Если
хочется иметь "вечную" цель, то, как и redo-c, как и apenwarr/redo,
отсутствие файла воспринимают как тухлость. Последние правки в redo-c
не удаляют файл, если stdout был пуст -- это ломает подобный подход. Я
поэтому делал revert коммита. Ибо это добавляет гибкости и отсутствие
проблем из-за хэширования пустоты. В итоге имеем и гибкость и false
positive защиту хэшом. Если покажется кому-то медленным, то добавил
возможность отключения хэширования (как apenwarr/redo будет). Для хэша
использую BLAKE2b
* я явно делаю sync для созданных целей и файлов зависимостей, а также
директорий после переименования файлов. Можно отключить. apenwarr/redo
не делает sync ни для целей, ни для SQLite3 БД, явно отключая
синхронность
* распараллеливание работы делается через jobserver-like протокол, но с
возможностью infinite работ. У меня на C проекте это позволяет сверх
быстро собрать его
* у меня разукрашенный вывод, с удобными indent-ами, возможностью показа
когда цель завершена и сколько это заняло времени, возможностью
показа PID-ов. stderr задач можно тоже показывать с PID-ом самого
shell-скрипта выполняющегося. У меня сверх verbose debug вывод, весь
из себя разукрашенный, показывающий все принимаемые решения и шаги
* stderr каждой цели можно сохранить на диск автоматом, но в нём каждая
строка будет ещё и с TAI64N timestamp-ом, совместимым с tai64nlocal
утилитой. redo-log команда позволит просмотреть его
* состояние хранится в .dep файлах которые являются recfile-ами
(8249370437018ad186c7946f22242731fba52035, d47bdefa40f41b81435565029c035f62614fe0da)
Особо надобности в этом нет, oneline формат redo-c не проблематичен,
но так красивее, мне кажется
* в процессе работы создаются временные файлы, которые при убийстве
процесса не подчищаются. Сделал отдельную redo-cleanup команду для их
подчистки и возможности вообще удаления .redo отовсюду, для начала с
чистого листа
* apenwarr/redo даже в FAQ говорит что скорее всего начнёт создавать
.redo поддиректории в каждой директории, ибо не понятно как выяснять
что является верхним уровнем проекта. Я сделал подход redo-c: вплоть
до корня ФС он будет искать .do файлы. Но, с возможностью ограничения
"сверху" через REDO_TOP_DIR переменную или наличию .redo/top файла.
И оптимизация и безопасность если проект и подпроект используют redo,
но должны быть независимы друг от друга. Насколько понимаю,
apenwarr/redo тут будет иметь проблемы
Наконец, goredo имеет "gore" корень, что не может меня, любителя
goregrind, не радовать. Это один исполняемый файл, на который нужно
создать символические ссылки. Точнее запустить с -symlinks опцией, чтобы
он это сделал сам.
goredo в итоге работает и собирает проект даже на глаз ОЩУТИМО быстрее.
Всё же, как ни крути, но Python это Python и быстро запуститься
программа на нём не может. Чтобы просто перезапустить rebuild, который
пройдёт по целям делающим redo-stamp, apenwarr/redo нужно время заметное
на глаз, тогда как goredo отрабатывает вмиг. В общем, пока для меня это
идеальная redo реализация!
Смотрел ли я ещё на какие-нибудь?
* Haskell реализация поддерживает только redo-ifchange. Да, это основное
и главное, но нет, хочется большего
* Есть 2-3 реализации на shell (не считая работающего apenwarr/do, но не
делающего rebuild), но либо они требуют либо GNU утилит, либо вообще
bash (идёт сразу в жопу)
* redux на Go я даже пробовал запускать. Он создавал какое-то дичайшее
количество (многие мегабайты) JSON файлов, но .do вроде запускал.
Только с безумно низкой скоростью это всё работало и я даже через
десятки секунд (минуты?) не дождался конца и нажал Ctrl-C. Просто
неюзабельно
* C++ не смотрел, ибо нафиг этот язык, тем более для выполнения redo задачи
* Отпадают не совместимые с redo(-ifchange) реализации
И только с написанием goredo я наконец-то понял надобность в
redo-ifcreate! Например есть цель "foo", но нет "foo.do", а есть
"default.do" (где-нибудь). Если в зависимости будет прописано только
"foo" и "default.do", то появление "foo.do" не заставить цель протухнуть!
Поэтому пути поиска default.do файлов автоматически прописываются в
зависимости, как-будто был вызван redo-ifcreate. Очень красиво, на мой
взгляд. Как пользователь, я redo-ifcreate так и не знаю где вызвать, но
внутри без него вижу что нельзя. Ведь и зависимость от .do файла явно
никто не прописывает -- оно автоматически.
Sergey Matveev [Thu, 19 Nov 2020 13:07:19 +0000 (16:07 +0300)]
Много людей подписались на рассылку LEAPSECS
https://pairlist6.pair.net/pipermail/leapsecs/2020-November/007275.html
Именно сегодня. После статьи из 273d4d5a49d90e55fbd5a173cf587fe09f8b03e7.
И я ведь тоже после неё подписался, интересно же!
Sergey Matveev [Thu, 19 Nov 2020 12:28:03 +0000 (15:28 +0300)]
Самая популярная покупка с первой зарплаты
https://lenta.ru/news/2020/11/19/pervazarp/
Одежда, гаджет, отдых, развлечения или отдали родителям. Ну меня за пару
месяцев зарплата ушла на Beyerdynamic наушники. Модель которую с тех пор
только и использую, ни на что не променяв.
Sergey Matveev [Thu, 19 Nov 2020 07:30:22 +0000 (10:30 +0300)]
Самая популярная песня всех времён
https://lenta.ru/news/2020/11/18/shazamtrack/
https://www.youtube.com/watch?v=q0hyYWKXF0Q
https://www.youtube.com/watch?v=fiore9Z5iUg
https://www.youtube.com/watch?v=PBZfCmlRIVs
https://www.youtube.com/watch?v=SsYXnH9lzCY
... по мнению Shazam. Ни одного исполнителя не знаю, ни одной песни не
слышал. Заценил. Я даже не могу сказать что "это не моё", ибо мне
реально жутко не нравится всё услышанное. Как минимум, отсутствие
голосов. Просто противно и неприятно их слушать. В них нет ни изюминки,
ни красоты, ни души. Мне например очень не нравится манера исполнения и
голос (тембр?) Bon Jovi, Nickelback особенно -- но у них выделяющиеся и
запоминающиеся, просто на любителя. А тут... просто какие-то сонные
подростки бубнящие в микрофон. Да и музыка... настолько уныла, скучна и
просто никакая, что наверное это причина почему в моём предыдущем посте
Земля даже стала медленнее вращаться!
С одним трэком "Let Her Go" я всё же знаком только потому что Within
Temptation на одном из bonus альбомов исполнили на него кавер:
https://www.youtube.com/watch?v=xJrEvz6nbv8 -- но даже он у них является
самым унылым. А вот кавер на Imagine Dragons "Radioactive"
(678bb3bee703cc2fc2d2a427b970c9b1a4ffb08a), так меня бесящий в оригинале
(но! вокалист всё же петь умеет, есть изюминка!), у Within Temptation
отличен: https://www.youtube.com/watch?v=hKDxvVom64c
Sergey Matveev [Thu, 19 Nov 2020 07:07:36 +0000 (10:07 +0300)]
Отправка <...> сообщений в IM-ах
https://rachelbythebay.com/w/2020/11/18/signal/
В Signal, как тут пишут, нельзя отправить сообщения в которых есть
что-то похожее на HTML тэги. Ну офигеть, а люди ещё умудряются говорить
что IM-ы это удобно, когда даже выхлоп ifconfig нельзя отправить.
Sergey Matveev [Tue, 17 Nov 2020 15:22:10 +0000 (18:22 +0300)]
pygopherd выпилили из Debian потому что не поддерживает Py3
https://lists.debian.org/debian-user/2020/11/msg00319.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937449
Хотя там всё же можно оставить было пакет если количество пользователей
большое. Как же мне много чего в Debian не нравится стало, и тут вот
очередные решения основанные на популярности.
Sergey Matveev [Tue, 17 Nov 2020 15:17:25 +0000 (18:17 +0300)]
cut vs awk
https://www.datagubbe.se/cutvawk/
Увидел в статье клёвый хак с tr -s " ". Его мне очень недоставало в tr!
awk я считаю лет 30 назад должен был перестать использоваться уже. Есть
Perl, полностью с потрохами легко заполняющий его нишу. Но awk я, к
сожалению, продолжал иногда использовать для print XX вещей. С tr хаком
уж точно перестану.
Sergey Matveev [Tue, 17 Nov 2020 11:43:41 +0000 (14:43 +0300)]
Интервью с Ангусом Янгом -- он тоже был впечатлён Хендриксом
https://www.darkside.ru/news/126147/
Почти все гитаристы упоминают что Хендрикс был крутейшим богом гитары.
Согласен с этим. Но также запомнилось что от Ангуса я не слышал про
Джимми упоминаний. Не то чтобы я много интервью с ним читал и слышал, но
вот не попадалось. А оказалось что Хендрикс то его впечатлил ещё как!
Purple Haze -- то самое!
А ещё Ангус оказывается совершенно в отказе от любого алкоголя! Не знал
про этот факт. Здорово! И я тоже вообще ничего алкогольного
принципиально не употребляю.
Забавно, а интервьювер впервые поцеловался под Thunderstruck AC/DC. Меня
немного удивляет, ибо как можно отвлекаться даже на такую штуку, когда
такая композиция играет!
Sergey Matveev [Tue, 17 Nov 2020 09:39:36 +0000 (12:39 +0300)]
Использую GNU Stow и для штатной его задачи
В f25380e9842d68f2f9ecce0d530db90903eeb66b коллега поднял тему по
иерархии директорий и устройству/установке пакетов. При этом упомянул
GNU Stow. С того момента всё не выходил он у меня из головы, ведь я его
уже использую для dotfiles (94dad30d714080ca9eb403277a4c923b54bc20c3),
но не использую для штатной цели! А ведь у меня в домашней директории
было много программ установлено (mutt, git, ffmpeg и десяток других),
которые я не хочу глобально в систему ставить. Каждая программа стоит
просто в $HOME префиксе и я в .zshenv добавлял PATH/MANPATH/INFOPATH для
неё. Только сегодня дошло что нафига я этим занимался, ибо Stow как-раз
для этого! Засунул все программы в $HOME/local/stow и он сделал нужные
symlink-и и про .zshenv я могу забыть теперь. Очень удобная штука!
Причём, кроме GNU grep и GNU sed (ну и recutils), без которых можно
прожить и я их использую только из-за производительности, я активно
использую и очень рекомендую GNU parallel и GNU Stow -- оба которых
написаны на Perl. Можно сказать, среди всего GNU софта я только на Perl
написанный считаю must-have-ным :-)
Sergey Matveev [Mon, 16 Nov 2020 19:01:08 +0000 (22:01 +0300)]
pkg-config нравится
https://people.freedesktop.org/~dbn/pkg-config-guide.html
В целом я считаю что freedesktop.org делает в основном плохое, но
pkg-config мне нравится. Только сегодня дошли руки причесать
генерирование корректного .pc файла, который позволяет парой вызовов
получить реально все CFLAGS/LDFLAGS/LDLIBS нужные для сборки. Requires
справляется с тем, что указав зависимости, он и их CFLAGS подставит все.
А у себя в проекте прям определяю какие зависимости определились через
pkgconf, добавляя их в итоговый requires, а какие нет, добавляя их
*FLAGS/LDLIBS уже к соответствующим секциям. К сожалению, проблема на
практике в том, что не все библиотеки предоставляют .pc файлы. Но,
благо, их легко делать. Но даже suckless проекты его вовсю используют и
поэтому их сборка не вызывает проблем и, тем более, какого-нибудь ада в
виде autotools.
Sergey Matveev [Mon, 16 Nov 2020 17:33:02 +0000 (20:33 +0300)]
Посмотрел "Вторую жизнь Уве"
https://ru.wikipedia.org/wiki/%D0%92%D1%82%D0%BE%D1%80%D0%B0%D1%8F_%D0%B6%D0%B8%D0%B7%D0%BD%D1%8C_%D0%A3%D0%B2%D0%B5_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Очень понравился фильм! В целом он конечно грустный и печальный, но
забавные моменты ещё какие есть. Заканчивается, я считаю, на хорошей
ноте, мол главный герой много кому оказался полезен. Но в жизни я думаю
таких не много найдётся.
Вообще у меня в блоге как фильм ни упоминается, то он мне понравился. На
самом деле я смотрю их в разы больше, но они настолько не стоят отзыва
(если это не редкостная гадость), что просто об этом умалчиваю, стыдясь
что взялся такое смотреть.
Sergey Matveev [Mon, 16 Nov 2020 17:23:21 +0000 (20:23 +0300)]
Blockchain and trust статья Шнайера. Голосование на blockchain
https://www.schneier.com/blog/archives/2019/02/blockchain_and_.html
https://www.schneier.com/blog/archives/2020/11/on-blockchain-voting.html
Удивительно, но я почему-то не читал эту статью раньше у него. Люто
нравится, так как в ней повторены аналогичные мои point-ы почему
BitCoin/blockchain бесполезны:
[...]
Blockchain technology is often centralized. Bitcoin might
theoretically be based on distributed trust, but in practice, that’s
just not true. [...] With bitcoin, there are only a few miners of
consequence. There’s one company that provides most of the mining
hardware. There are only a few dominant exchanges. To the extent
that most people interact with bitcoin, it is through these
centralized systems.
[...]
Do you need a public blockchain? The answer is almost certainly no.
A blockchain probably doesn’t solve the security problems you think
it solves.
[...]
Honestly, cryptocurrencies are useless. They’re only used by
speculators looking for quick riches, people who don’t like
government-backed currencies, and criminals who want a black-market
way to exchange money.
А вообще там сплошная тема про доверие и то что доверие нельзя заменить
алгоритмами и протоколами. А вышел на эту статью я через "On blockchain
voting", где тоже сказано что для голосования использование blockchain
вообще тупейшая идея.
Честно говоря я переживал что Шнайер не высказывался о blockchain-ах и
даже наоборот где-то по началу говорил что идея неплохая. Я вот такой
упёртый и считаю Bitcoin/blockchain -- сущим глупым hype-ом, не несущим
никакой практической пользы (ну, кроме продавцов электроэнергии, железа
и спекулянтов, конечно же), а Шнайер, мол, нет и может быть я всё же не
прав? Нет уж, оказалось что всё ok, мы с ним сходимся во мнении.
Столлман про Bitcoin плохо говорил потому что там нет анонимности, что
очевидно.
Sergey Matveev [Mon, 16 Nov 2020 14:50:11 +0000 (17:50 +0300)]
Apple firewall не поможет от программ от Apple
https://thenextweb.com/plugged/2020/11/16/apple-apps-on-big-sur-bypass-firewalls-vpns-analysis-macos/
В общем, это и не firewall оказалось, ибо прозрачен для софта от Apple.
Sergey Matveev [Mon, 16 Nov 2020 08:34:20 +0000 (11:34 +0300)]
Преимущества "Linux" перед Windows: длины имён файлов
https://github.com/nbeaver/why-linux-is-better
Только начал бегло смотреть по диагонали и вижу раздел с максимальной
длиной пути в Windows: 260 символов, а в "Linux" например 4096 (байт?).
И типа в Windows много проблем из-за этого. Насчёт полного пути не знаю,
но вот я не раз сталкивался с тем, что torrent-ы созданные под Windows
не могут быть записаны на некоторые ФС (в том числе ZFS), так как в
Windows ограничение на кол-во символов, а в Unix-ах на байты и кириллица
там становится раза в два длиннее (UTF-8) и уже не влезает: cdc44c7a1bb63c5822313ac73e99a39bda088bff. Но я считаю что 255
символов/байт это вполне себе достаточно.
В остальном же... особо больше мне ничего не приглянулось и не
запомнилось из этой здоровенной статьи.
Sergey Matveev [Sun, 15 Nov 2020 11:17:35 +0000 (14:17 +0300)]
Ваш компьютер больше не принадлежит вам
https://habr.com/ru/post/528104/
Ужасный перевод, но я и оригинал читал. Даже не стал комментировать, ибо
и так про отправку запускаемых команд уже упоминал.
(22dfdf4ab8cd4c68c15720af9296091114e3c3f7). Только Apple это малая часть
компьютеров. Но уже не одно десятилетие движение свободного ПО говорит
про то, что проприетарное ПО это когда вы не управляете своим компьютером.
Особенно всё усугубляется когда компьютер подключён к Сети. Это одна из
причин почему я принципиально не связываюсь с проприетарщиной, в том
числе и JavaScript программам, которые многие не относят/не приравнивают
к запуску несвободного кода.
Sergey Matveev [Sat, 14 Nov 2020 20:50:44 +0000 (23:50 +0300)]
Mike Fraser
http://mikefrasermix.com/credits/
Этот человек создал наверное четверть вообще всех альбомов что у меня на
жёстком диске! Только одних AC/DC пять штук! У некоторых и звук свой
неповторимый -- например группа Septicopyemia обращалась к чешскому
чуваку что сводил альбомы Jig-Ai и звук у них получился именно таким же,
чешским горграйндовым, как и должен быть!
Sergey Matveev [Sat, 14 Nov 2020 20:34:08 +0000 (23:34 +0300)]
Сборка redo проекта в отдельной build директории
В 401c0f635a1cdfb01068a48a4cdf40791d3db458 писал про полную нормальную
замену autotools redo целями. apenwarr/redoconf по многим причинам мне
не нравится, но он умеет делать (даже заставляет) отдельные, независимые
от кода build-директории. Я у себя нашёл как это реализовать: банальный
и простой shell-скрипт который просто делает иерархию директорий и
жёсткие ссылки на файлы исходного кода. Полностью воссоздаются
директории (find+mkdir, find+ln): conf doc examples src tests, а также
копируется эталонный config файл (с -i опцией, чтобы не перезатереть
ненароком) и базовые {all,install,clean}.do цели. Отрабатывает быстро,
место в общем-то не занимает весь этот исходный код. Ни одного .do файла
не правил. Можно сказать что просто весь проект я жёсткими ссылками
переношу, ну и ладно. Зато теперь я с разными опциями (точнее конфигами)
могу параллельно напересобираться для проверок.
Sergey Matveev [Sat, 14 Nov 2020 13:17:10 +0000 (16:17 +0300)]
Замена autoutils redo системой
https://redo.readthedocs.io/en/latest/cookbook/redoconf-simple/
В моей C программе всё усложняется конфигурация сборки: есть
опциональные библиотеки, есть выбор методов/библиотек, появилась
зависимость между некоторыми переменными конфигурации. Если выбран метод
использования криптографии из библиотеки YYY, а не XXX, то всякие
XXX_CFLAGS=${XXX_CFLAGS:-`$PKG_CONFIG --cflags xxx`} исполняться не
должны. Их можно просто закомментировать, но это ручной труд. Добавлять
массу if-ов в сам конфиг (который обычный shell файл) -- тоже плохо,
хотя в нём уже есть hardcoded вещи типа добавления -pthread если
включено использование pthread mutex-ов. Плюс пользователю нужно явно
задавать pkgconf/pkg-config команду например, хотя она может быть
определена сама. Некоторые команды (plantuml, dmalloc) опциональны. В
общем или существенно усложнять простой config, который выглядит просто
как какой-то .ini файл, либо... что-то придумывать.
Определение команд, определение наличия библиотек (у меня опциональные
libtai, dmalloc, libtap например) -- всё это отдельные изолированные
друг от друга задачи. Между ними могут быть зависимости, как например
$CRYPTO_CFLAGS зависит от флагов конкретно выбранной криптобиблиотеки.
Раньше config содержал вереницу переменных внутри которых были вызовы
pkgconf, которые запускались все последовательно. Всё это (отдельные
задачи, зависимости между ними) явно задача для системы сборки!
Я помнил что в apenwarr/redo реализации есть redoconf -- штука которая
как-раз для замены ./configure ада, в которой можно набросать отдельными
файлами всякие детекторы. Я по сути взял из неё идеи, но саму
использовать не стал. Во-первых, там намёки на GNU Make. Во-вторых, она
банально просто где-то падала и не работала у меня -- что-то не так в
shell-скриптах. В-третьих, это полноценный такой framework, с кучей
библиотечных shell функций и обёрток -- требующий и изучения и уже не
такой и прекрасный как redo, не привязанный к языкам или чему-то
подобному. В-четвёртых, там очень много делается через создание shell
файлов с соответствующими костылями для всякого escape-а данных.
В-пятых, там подход заточен чтобы делать один большой и жирный compile
скрипт, содержащий все CFLAGS/LDFLAGS/LDLIBS для сборки целей. Я же у
себя для каждой конкретной .o-цели явно задаю и управляю какие конкретно
опции и флаги передаются -- чтобы лучше понимать что от чего зависит.
Но основную идею я заимствовал. Если программа использует $CC, то можно
сделать вот такой детектор, который учитывает и переменные окружения:
можно добавить зависимость от цели учитывающей изменение переменных
окружения (0676a1348e8ffe14a7840c8699d3afdc6857e24c) и учитывать не
поменялось ли значение самой цели:
проверка наличия redo-stamp чтобы работало под реализациями без этой
команды -- всё будет работать, просто изменение переменных окружения не
заставит пересобираться (если системы не основаны на хэшах, конечно же).
Программа которой нужна cc команда:
redo-ifchange ../conf/cmd/cc
read CC < ../conf/cmd/cc
$CC ...
Сделать более сложные цели для определения команд, возможно с выводом в
stderr о том что команда не найдена и будет использоваться пустышка --
тривиально. Раньше у меня всё глобально зависело в целом от конфига и
переменных окружения (его касающиеся). Теперь команды сборки
документации зависят только от cmd/makeinfo, cmd/plantuml (который
подставит пустышку, с предупреждением, если настоящий не найден) и
изменение cmd/cc не повлияет на пересборку документации. Плюс для сборки
некоторые .o файлов нужны знания о PCSC библиотеке, добываемые через
pkgconf. Для других .o файлов нужен LibreSSL, тоже через pkgconf. Обе .o
зависят от разных conf/flags/{crypto,pcsc} флагов и поэтому вызовы
pkgconf-а могут быть распараллелены. Определение наличия и
работоспособности libtai библиотеки делается через сборку (прямо внутри
conf/flags/tai) временного файла с C кодом, но знание о $TAI_*FLAGS
нужно только при сборке log.o файла -- пока он дожидается сборки и
проверки наличия libtai, множество других целей уже успеет собраться,
так как они не зависят от conf/flags/tai.
Многие .o зависят от криптографических библиотек. Но им без разницы
какая именно библиотека будет использована. Поэтому я использую общие
$CRYPTO_*FLAGS, значение которых зависит от выбранного метода
криптографии:
тут и зависимость от конкретной pkg-config реализации и возможность
переопределения SSL_* и выхлоп просто в виде трёх строчек в файл.
Библиотеке которой надо использовать CRYPTO_*:
redo-ifchange ../conf/flags/crypto
read CRYPTO_CFLAGS < ../conf/flags/crypto
# или
{ read X ; read X ; read CRYPTO_LDLIBS ; } < ../conf/flags/crypto
Подход с read-ом мне люб тем, что не надо париться с экранированием и
генерированием валидного shell-кода. Изначально у меня был lib.rc с
библиотечными shell функциями, но под конец полностью исчез.
В итоге, что я получил?
* возможность лёгкого добавления детекторов как и в autoconf. Сейчас у
меня в проекте 14 conf/cmd и 19 conf/flags (всякие флаги сборки кода).
Плюс с зависимостями между ними
* полное распараллеливание работы этих детекторов
* зависимость конкретных целей сборок совершенно разнородных вещей
(документация, .o файлы, исполняемые, .a) от только нужным им командам
и флагам/настройкам
* при изменении переменных окружения (хочу быстро всё пересобрать с
CC=clang-NEW redo clean install) будут пересобраны только зависящие от
CC цели (например сгенерированный asn1Parser-ом файл .c из .asn1
спецификации не будет затронут). Зависимость только от конкретики
Это всё просто офигенно! Есть небольшой недостаток моего подхода: вместо
"redo-ifchange ../vars ; . ../vars" у меня большее количество
зависимостей и из-за read-а каждое чтение каждой команды/флага занимает
строчку. Но зато чистейший pure POSIX shell, никаких shell фунок
самопальных, отсутствие хаков и возни с экранированием строк, которая
присутствовала раньше (а у apenwarr/redoconf так вообще там целые экраны
кода для этого).
Для того чтобы узнать какие вообще опции можно изменить/настроить в
apenwarr/redoconf -- вызывают отдельные функи "регистрирующие" что у нас
есть на руках. У меня в каждом "детекторе" команд/флагов/настроек есть
возможность влияния на него через переменные окружения или тем что
прописано в config-файле. Де-факто это всегда запись/использование
переменных в виде ${WHATEVER}. Что мешает мне просто из всех .do
навыдёргивать эти переменные?
Почему в одном месте perl, а в другом sed? Так исторически сложилось,
лень переделывать :-). После выполнения, я получу красивый полный
список:
AR ARM_CFLAGS ARM_LDFLAGS ARM_LDLIBS ASN1PARSER CC CFLAGS CLANG_FORMAT
[...]
TAI_LDFLAGS TAI_LDLIBS TAP_CFLAGS TAP_LDFLAGS TAP_LDLIBS TASN1_CFLAGS
TASN1_LDFLAGS TASN1_LDLIBS VERSION
Без описания переменных правда. Но пока все они говорят сами за себя и
должны быть понятны. Для их описания уже понадобится конечно куда-то
зашивать эту метаинформацию, например просто в виде комментария рядом с
переменной оставлять и чуть-чуть усложнённым perl скриптом выдёргивать.
Когда я начал всю эту переделку, то совершенно полностью не был уверен в
результате и вообще будет ли оно того стоить. Превзошло все ожидания!
Единственное чего у меня совершенно нет, в отличии от apenwarr/redoconf
-- возможности работы в отдельной изолированной build директории, что
вообще конечно хорошим тоном является. Пока даже не думал как это сделать.
Можно просто наворотить себе git worktree в отдельных директориях, как хак.
Sergey Matveev [Sat, 14 Nov 2020 08:21:25 +0000 (11:21 +0300)]
Скорость работы LLVM 11 и его инструментарий
Обновился с LLVM 6 до 11. LSP демон стал работать значительно быстрее,
меньше каких-то непонятных warning-ов выдаёт. В 543ea92f9b81c1c8adead550e7ce0cf3cc665240 писал про то, что скорость
прежних задач не должна падать -- тут они справились! А вот всякие
clang-tidy стали работать медленнее... но при этом находят больше
серьёзных недочётов и в (ещё не протестированном) коде нашли утечки
памяти (отсутствие free) и кое где отсутствующие break. За это можно
простить, тем более что оно не интерактивное.
Вообще LLVM/Clang инструментарий очень нравится и насколько понимаю в
GNU GCC нифига подобного ничего нет. И clang-format, который 100%
форматирует весь мой код. scan-build ПОТРЯСАЮЩЕ находящий серьёзные
ошибки, которые и во время ревью человек то нифига не заметит (хитрые
goto/if из-за которых потеряется значение переменной). clang-tidy
выдающий и false positive, но также и полезные вещи типа утечек памяти
или неинициализированные значения. clangd LSP -- как linter отличен!
Куча -Weverything проверок (которые даже в doxygen docstring-и умеют
залезать) и sanitizer-ов, которые в 99% случаев находили некорректности
работы с памятью, переполнения чисел или ошибок из-за их знаковости.
Вовсю моё программирование на C опирается на эти инструменты.
Единственное что я ставил дополнительно это: https://include-what-you-use.org/
С помощью которой я легко корректно и правильно организую include-ы,
ведь задача очень не приятна для человека.
Sergey Matveev [Sat, 14 Nov 2020 08:12:50 +0000 (11:12 +0300)]
Иерархия файловой системы в Unix-like системах
https://cr.yp.to/slashpackage.html
https://jdebp.eu/FGA/slashpackage.html
https://sta.li/filesystem/
Коллега скинул ссылки на очередной предложение от DJB касательно
управления "пакетами". Точнее того, как их можно было бы устанавливать и
размещать. jdebp.eu продолжает идею ещё дальше. Такой подход мне
нравится, безусловно. Плюс /var/service где daemontools смотрит за
демонами. У sta.li тоже видел предложение по куда более простой
иерархии:
/ - the root home
/bin - all executables
/sbin -> /bin # softlink pointing to /bin
/boot - all boot files
/etc - system configuration
/home - user directories
/var - spool, run, log, cache
/share - man pages, locales, dependencies
/include - include/headers
/lib - static libraries for building stuff
/mnt - mount points
/usr -> / # softlink pointing to /
/sucks - stuff that sucks, like ugly gnu library dependencies,
or systemd fake handlers
Которое мне тоже нравится. Но вот менять это в уже готовой ОС, типа
FreeBSD, не стал бы. Оно красивее, правильнее, но стоит ли оно того?
Если делать дистрибутив/ОС с нуля, то стоит обо всём это задумываться. А
так овчинка выделки не стоит -- уж больно много геморроя.
Хотя это ужасно что мы стали жить в /usr и /usr/local директориях, ведь
история говорит что просто у хакера не хватило места в / ФС и было много
свободного на /usr и поэтому он туда начал всякое устанавливать.
Sergey Matveev [Sat, 14 Nov 2020 08:00:02 +0000 (11:00 +0300)]
glibc и memset_s
https://en.cppreference.com/w/c/string/byte/memset
Компилировал недавно свою программу на последней LTS Ubuntu, GCC10.
Отругала меня что ничего не знает про memset_s функцию (безопасная
очистка памяти). Действительно grep вообще ничего не показал. Как же
так? А вот так, действительно, glibc положил на опциональные C11 функции
связанные с security. Даже не самая свежая FreeBSD имеет их у себя в libc.
Я то думал что наконец-то в 2011-ом году догадались стандартизировать
наличие функции безопасной очистки памяти. Сделать то сделали, вот
только в GNU/Linux мире это не реализовано. Когда-то я считал что GNU
софт и библиотеки монструозны по размерам, но при этом чего только не
содержат и богаты функционалам. Теперь вижу что они просто монструозны!
Sergey Matveev [Sat, 14 Nov 2020 07:56:37 +0000 (10:56 +0300)]
Power Up!
https://en.wikipedia.org/wiki/Power_Up_(album)
Вышел новый альбом AC/DC и даже нашёл где его скачать! Хорош ли он?
Слушал перед сном. Когда проснулся сегодня -- до сих пор что-то из него
играло в голове и хотелось его переслушать. В отличии от трёх предыдущих
(20 лет времени) -- в нём уже рок-н-ролльчик, а не блюз, который после
прослушивания у меня ничего не оставлял в памяти. Альбом хорош!
Вот правда сразу же бросилось в уши что он жутко скомпрессирован! Очень
громкий. Но всё же слушать можно, в отличии от Metallica "Death Magnetic".
Sergey Matveev [Sat, 14 Nov 2020 07:46:52 +0000 (10:46 +0300)]
Рекомендации к просмотру xkcd
Сегодня заметил что на сайте xkcd.com есть рекомендации просмотра:
xkcd.com is best viewed with Netscape Navigator 4.0 or below on a
Pentium 3±1 emulated in Javascript on an Apple IIGS at a screen
resolution of 1024x1. Please enable your ad blockers, disable
high-heat drying, and remove your device from Airplane Mode and set
it to Boat Mode. For security reasons, please leave caps lock on
while browsing.
Sergey Matveev [Sat, 14 Nov 2020 07:45:14 +0000 (10:45 +0300)]
musl то требует Linux
http://www.musl-libc.org/faq.html
Я про musl упоминал что штука выглядит хорошей, но ни в коем случае даже
мысли не было чтобы его использовать у себя на FreeBSD. У нас и так
хороший BSD libc. А даже если бы и захотелось, то musl всё равно требует
Linux ядро.
Sergey Matveev [Fri, 13 Nov 2020 09:29:08 +0000 (12:29 +0300)]
Прочитал "Пиратов Карибских морей"
https://www.livelib.ru/book/1000250586-piraty-karibskih-morej-v-riva
С одной стороны получил удовольствие, а с другой как-будто какой-то
бабских роман прочитал, где сплошные интриги и козни на теме любви.
Запомнилось что очень тяжело даётся идентификация героев романа: имена
всюду и везде есть, но вот тяжело мне они запоминаются и я часто только
по контексту понимал кто к кому пришёл. Ну как в некоторых просмотренных
корейских фильмах все на одно лицо.
Sergey Matveev [Fri, 13 Nov 2020 07:54:06 +0000 (10:54 +0300)]
Железо на шаг впереди, софт делает два шага назад
https://fabiensanglard.net/silicone/index.html
Автор пишет что, не смотря на возрастающую производительность
процессоров и железа в целом, на каждую сохранённую железячниками
инструкцию, софт умудрится сделать на две инструкции больше. Меня
впечатлило что автор говорит что раньше Photoshop на SSD грузился
за секунду, XCode запускался мгновенно. А теперь на Ryzen 5 2600 с
M.2 NVMe он уже просто не в состоянии использовать XCode и Photoshop
грузится на 13сек!
Это нормально что raytracer-ы требуют больше ресурсов потому что они
делают более качественную и лучшую картинку. Компиляторы получили всякие
LTO оптимизации, которые тоже ресурсоёмки. Но вот не нормально что
прежние такие же задачи на новом железе выполняются так же долго.
Именно в этом году я конкретно начал замечать и париться об отзывчивости
системы. Я делал это и прежде, но в этом году у меня обострение какое-то.
* Давным давно я выкинул bash, в первую очередь потому что он медленный.
Я уже не вспомню где и как именно, но он тупо просто некоторые чисто
shell вещи умудряется делать так, что я на глаз замечаю задержку.
* Для калькулятора я часто запускал python -- и даже на современных
мощных Mac системах (коллега проверял) "не прогретый" запуск занимает
более секунды! Если мне надо посчитать в калькуляторе что-то, то я,
очевидно, хочу его моментальный запуск! Это происходит не часто,
поэтому к долгому времени запуска я привыкнуть не могу. Я перешёл на
zcalc, а теперь вот на dc в rlwrap в tmux с кучей shell-скриптов
обёртки -- и это работает стремглав, по сравнению с запуском python.
* За последний год я больше работал с Go и не переставал удивляться что
он способен откомпилировать с нуля mumble-сервер, жирный irc-сервер с
кучей зависимостей за считанные секунды!
* Когда я что-то рассматриваю и пробую из плагинов для Vim-а, то
скорость работы (или я замечу задержку или нет) практически на первом
месте. Возясь с LSP увидел что скорость работы Python LSP сервера
такая, что я полностью отключил его, ибо мне проще и удобнее руками
вызывать pylint/pyflake/whatever, а не получать с дичайшей
асинхронностью по времени warning-и, которые уже не актуальны могут
быть. Linting clangd для C работает вполне вполне с достаточной
скоростью и помогает, но вот дополнение методов/функций работает очень
медленно -- автоматику во время набора поэтому отключил. А вот в Go
LSP работает практически со скоростью моего набора!
* Когда я стал использовать redo со всякими pkg-config-ами, то весь
процесс конфигурирования+сборки+установки стал таким быстрым (для моих
проектов, конечно же), что мне почти физически становится плохо когда
я вижу что на моём ноутбуке ./configure выполняется дольше чем сама
сборка. Это проблема configure, но всё же!
* Когда я стал программировать на C, то вижу с какой скоростью всё
способно компилироваться. C++ -- адовейший ад. У коллеги с мощным
компьютером видел сколько собирает Rust программу типа PyDERASN-а --
ещё большее время ожидания, при котором можно прочитать новости успеть
* Недавняя эпопея с статической/динамической линковкой показала
насколько много впустую тратится время *человека* ожидающего запуск
программы
* Texinfo собирает мою домашнюю страницу всё равно секунды, но это на
порядок быстрее чем Python Sphinx. Не то чтобы это критично, но к
быстрой работе команд/задач очень привыкаешь и офигеваешь как в
некоторых проектах дока собирается по несколько минут. Давным давно
для вырезания docstring-ов и их вставки в .texi/.rst файлы у меня был
Python скрипт и при частой сборке программ я бОльшую часть времени мог
ждать только факта самого его запуска. Сейчас у меня быстро написанная
программка на Perl -- работающая просто моментально для глаза (Perl
вообще очень и очень шустрый)
* Буквально ведь всего несколько лет назад, когда в FreeBSD был GCC,
сборка полностью всей ОС занимала меньше (на в разы более слабом
железе) чем сборка сейчас LLVM-а. CMake собирается дольше чем GCC (не
самый последний GCC, конечно же, где вроде как тьма C++ появилось). А
скорость сборки всей системы важна, если бы мы максимально старались
делать статическую линковку (c0de9bbf633b421a57a10db70d6d76b5f195546e).
Сборка Go, начиная с 1.4, занимает суммарно (без тестов) наверное пару
минут на ноутбуке
Отзывчивость системы это life-changing! Это не просто "ну, приятно что
быстрее запускаются", а это именно в корне меняет привычки и работу за
компьютером. Огромное количество людей уходит с жирных IDE на Emacs/Vim
только потому что на их 16GB RAM системах оно всё равно всё тормозит (с
моей точки зрения -- до неюзабельного состояния).
Буквально позавчера я устанавливал Ubuntu последнюю LTS на флешку
(обычную такую дешёвую флешку), чтобы на отдельном ноутбуке поработать с
железом и с ней. В ней так много всего позапущено (без GUI! это server
вариант), что когда мне показали приглашение для логина, то логин занял
более чем минуту, прежде чем я увидел строку shell-а! Каждая, *КАЖДАЯ*
команда имеет видимый и ощутимый lag. На этой же флешке я помню как
запускал FreeBSD с GUI и Firefox-ом -- это была юзабельная система.
Большие лаги я наблюдают когда соединяюсь с удалённым VPS-ками по IPv6,
который идёт через третьи страны -- вот на современных Ubuntu,
запущенных на локальном железе, ощущения похожие.
Я, как программист, часто понимаю, конечно же, откуда растут ноги всего
этого, но нужно же иметь совесть! Отдельная тема это смартфоны и
броузеры (штатные, где ничего не отключено из JS-а) -- где всё медленно
и неспешно, в slow-mode-е. У папы на смартфоне я вижу задержку наверное
чуть ли не на каждый клик (не в броузере, а просто в системе), хотя
другие этого не замечают уже, ибо привыкли. Мне в фильмах всегда
бросалось что любое нажатие по любой кнопочке обязательно должно
открывать окошко/менюшку с анимированным визуальным эффектом. В Mac по
умолчанию когда показываются все текущие окна, тоже анимация их
размещения по экране. В фильмах это ладно и простительно. Но нормальный
человек рехнулся что ли за каждым частым действием ждать десятки/сотни
миллисекунд на свистоперделку, вместо того чтобы от компьютера сразу
получить ответ на свою команду? Знаю что в проприетарных системах этими
анимациями часто скрывают, на самом деле, долгое время запуска/работы,
но ведь не всегда же так.
Насколько мог бы "динамический" IPsec между host-to-host системами
(когда одна из сторон "анонимна" например) помочь с хранением
handshake/state и сократить до минимума лишние round-trip-ы до сервера,
дьявольски увеличив отзывчивость системы (HTTP/2 со всякими TLS session
resumption-ами это и пытаются добиться как-раз). Когда люди хотят чтобы
в каждой сетевой программке была поддержка TLS, то меня это бесит! IPsec
надо развивать, а не эти изолированные TLS сессии. Ведь нет же ничего
чтобы хранило state при запуске lynx, curl, wget, whatever -- наверное
только броузер одна из немногих программ которая долго живёт и может
блюсти уже установленные handshake-и. Life-changing когда я стал
использовать OpenSSH долгоживущие сессии и моментально логиниться на
сервер, а не ждать пока TCP/SSH handshake отработает и вся эта не
шустрая асимметричная криптография (пускай даже и *25519!).
Или вот на работе у нас используется OpenVPN. Под пять секунд приходится
ждать пока он подключится! А ведь ping до сервера вообще показывает чуть
больше 2мс!
На глаз видно насколько медленнее работает SSH или IKEv2 с RSA ключами.
Но это уже ладно -- это тема ни программистов, ни компьютеров. Но пора
активнее начать использовать эллиптические кривые.
Я бы на месте пользователей компьютеров и ресурсов Интернетов люто
ненавидел любого программиста, бессовестного и обнаглевшего!
Sergey Matveev [Thu, 12 Nov 2020 09:35:55 +0000 (12:35 +0300)]
Мужик два года заходил в квартиру через окно
https://lenta.ru/news/2020/11/12/man_seeking_woman/
И всё было удобно и прекрасно, пока к нему не пришла женщина и пришлось
тратиться и ломать замок двери. Жил, не тужил и тут на тебе!
Sergey Matveev [Wed, 11 Nov 2020 17:30:51 +0000 (20:30 +0300)]
Overhead от динамической линковки
http://harmful.cat-v.org/software/dynamic-linking/
http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols
https://sta.li/faq/
В комментарии http://blog.stargrave.org/russian/71870b1510dfc2727093f2767b994b8596f9b163#comment1
я запускал convert, в котором ldd на полэкрана, в течении 165мс. Когда
руками собрал с нуля, то у меня на полтора экрана вывод ldd и утилита
запускается более чем в два раза дольше. Всё таки 200мс это очень и
очень заметное на глаз время, тем более для long-live утилиты.
Когда я только начал в этом году программировать на C, то задавался
вопросом какие библиотеки мне делать (static vs shared). И все хакеры
говорят в один голос о статической линковке. Есть даже целый "stali"
(static linux) дистрибутив, целью которого является только статическая
линковка, musl и всякое такое. В котором много ссылок на конкретные
примеры всяких размеров программ, времени их запуска и тому подобного.
Plan9 и Go -- имеют только такую линковку.
И вот, судя по ImageMagick, я однозачно теперь тоже за статическую.
Во-первых, если использовать всякие -ffunction-sections+-Wl,--gc-sections,
то в итоговом исполняемом файле не останется лишнего кода в виде
неиспользуемых функций. Во-вторых, даже если размер будет и больше, то
он всё равно при этом будет быстро (быстрее) загружаться, что куда
важнее чем место на диске.
Основной аргумент за динамическую линковку у людей: типа если нужно
обновить OpenSSL, то можно только его обновить, не трогая остального. Но
даже я на своей практике с чистой совестью могу заявить что это брехня
только изредка работающая, ибо регулярно *на практике* несовместимости в
версиях библиотеки, которые препятствуют обновлению и по факту
приходится всё равно пересобирать зависимый от неё софт. Да и в чём
проблема пересборки всего что зависит от неё, пускай это даже и libc?
Отсутствие исходников? Не аргумент, ибо они должны быть в свободном ПО.
Проприетарное -- идёт нафиг. Время сборки/пересборки -- а вот это повод
задумываться над скоростью компилирования. C-компиляторы вполне себе
шустрые например. Go -- аналогично, пересобрать ВЕСЬ Go софт, сколько бы
его не было -- вопросы нескольких минут, как мне представляется на
практике. C++/Rust/etc -- теперь я ещё больше понимаю насколько важно
время сборки. А в идеальной и прекрасной системе со свободным ПО (значит
и исходники будут) на C/Go проблем нет никаких. Скорость,
производительность, простота, безопасность (куча ссылок касающаяся
недостатков динамической линковки про безопасность как-раз),
эффективность! Плюс никаких проблем с тем чтобы иметь софт с самыми
разносторонними по версиям зависимостями, ибо они всё равно вшиваются.
Sergey Matveev [Wed, 11 Nov 2020 16:39:59 +0000 (19:39 +0300)]
Линковка ld и порядок -l аргументов
https://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking
Работал я со своей C программой в LLVM/Clang/FreeBSD, работал в
GNU/Linux, GCC 4.x, glibc. А сегодня в современной Ubuntu с GCC10 не мог
собрать её. Упорно ругается что не может найти символы всякие, которые
из библиотек берутся. Беглый поиск "а не бага ли это GCC?" не дал
результатов. Начал тупо перебирать и менять местами все эти -l
аргументы чтобы заработало, ибо надо успеть это сделать довольно срочно.
Но позже нашёл вот статью в которой объясняет как именно обрабатываются
-l, что магии там нет, всё довольно просто. А я просто совершенно не
понимал (точнее подозревал, но в корне не верно) как линковщик работает.
А всё так "сложно" не просто так -- а чтобы быстро работал ld. Можно
указать пару аргументов (--{start,end}-group) и будет работать всегда и
везде, грубо говоря, но с соответствующим performance overhead.
Sergey Matveev [Wed, 11 Nov 2020 11:54:48 +0000 (14:54 +0300)]
Соскучился по Ubuntu
Давно я что-то про неё ничего не писал. Нужно тут собрать одну
библиотеку под неё. Скачал самый последний LTS. После установки, первым
же делом сделал apt install build-essential. Ну разве могло оно пройти
успешно?
[...]
Err:8 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 linux-libc-dev amd64 5.4.0-42.46
404 Not Found [IP: 2001:67c:1562::18 80]
Fetched 38.8 MB in 9s (4,546 kB/s)
E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc-dev_5.4.0-42.46_amd64.deb 404 Not Found [IP: 2001:67c:1562::18 80]
Ладно, apt-get update починил, ещё и GCC10 стал стягиваться.
Хочу установить libtap, libtai -- apt search по ним ничего не показывает.
Хотя в портах FreeBSD, например, обе имеются.
Sergey Matveev [Wed, 11 Nov 2020 11:45:16 +0000 (14:45 +0300)]
Python Concurrency From the Ground Up
https://www.youtube.com/watch?v=MCs5OvhV9S4
Очень понравилось выступление с живым показом как написать корутину на
Python, без asyncio, from the ground up.
Хоть у мужика и Emacs, но совсем не использует никакого автодополнения
(типа Ctrl-P из Vim), даже в bash всё любит набирать руками.
Sergey Matveev [Wed, 11 Nov 2020 09:31:30 +0000 (12:31 +0300)]
wpa_supplicant оказывается deprecated, как и ifconfig
https://losst.ru/top-5-prichin-ispolzovat-linux-v-2020
Чисто случайно из статьи вот узнал что wpa_supplicant оказывается тоже
уже устарел и вместо него используется wicd. Про него я не помню чтобы
слышал. Насколько ж давно я с WiFi последний раз работал под GNU/Linux!
Sergey Matveev [Wed, 11 Nov 2020 09:27:42 +0000 (12:27 +0300)]
HP почти переплёвывает Apple
https://www.linux.org.ru/news/hardware/15995352
HP удалённо блокирует принтеры, чтобы те не печатали. А ещё даже может
достучаться до них и через особые документы, отправляемые на печать
(чтобы и без Интернета мочь поднасрать). Скупердяйство не знает границ,
как верно заметили. До Apple конечно далеко, но всё равно удивляет эта
черта проприетарщиков.
Sergey Matveev [Tue, 10 Nov 2020 18:28:54 +0000 (21:28 +0300)]
В самолёте попоили собаку
https://lenta.ru/news/2020/11/10/dogplane/
... ну девушка начала оттуда же пить сама. Меня возмущают возмущения
людей :-). Да я сотни раз (тысячи?) так делал со всеми своими собаками,
давая и ложки облизывать, которыми сам же продолжаю есть, и из тарелки
или чашки чего полакать или там мороженое полизать.
Мерзкие пёсоненавистники!
Не забуду как хороша их слюна для заживления порезов/царапин! Был случай
когда я в детстве конкретно ободрал запястье, пришла собака наша, и
давай просто лизать это место. А я на компьютере вроде что-то смотрел.
Потом через несколько минут смотрю на руку -- а там и следа нет!
Sergey Matveev [Tue, 10 Nov 2020 18:15:07 +0000 (21:15 +0300)]
Конкурс красоты в Новой Зеландии
https://lenta.ru/news/2020/11/10/missnewzealand/
... выиграл мужик. Оказывается аналогично было и в Испании.
https://lenta.ru/news/2018/07/03/transmiss/
Там настолько всё плохо с женщинами, что на их конкурсах побеждают мужчины?
Или просто нормальным уже вход запрещён?
Sergey Matveev [Tue, 10 Nov 2020 11:32:57 +0000 (14:32 +0300)]
Тупость в статьях про качественный звук
В одном журнале вот увидел:
Однако теорема Котельникова не дает ясных критериев, какая частота
дискретизации нужна для КАЧЕСТВЕННОГО восстановления звукового
сигнала из цифровых отсчетов. Ведь при частоте дискретизации 44 кГц
на один период сигнала с частотой 22 кГц придется лишь 2 отсчета!
Замените период синусоиды всего двумя прямоугольными импульсами –
вот как искажаются высшие гармоники звукового сиг‐ нала в
аудиозаписях стандарта CD. И лишь низ‐ кочастотные гармоники
воспроизводятся довольно точно, так как на один их период приходятся
десятки‐сотни отсчетов. Отсюда следует, что для качественного
воспроизведения и за‐ писи аудио (например, в профессиональных
целях) нужна повышенная частота дискретизации (96, 192 кГц...) Для
решения этих задач по‐ явились «профессиональные» звуковые платы.
При этом возрос поток передаваемых данных, что потребовало
использовать более быструю шину PCI вместо ISA. Некоторые из этих
плат мы рассмотрим далее.
Автор явно и конкретно не понимает что говорит теорема Котельникова. Он
считает что раз на экране увидел два прямоугольничка (два отсчёта для
22kHz) и они не похожи на красивые синусоиды, то вот так вот всё адски
искажается. В 200bf7ba55111f981e69e8e89b7cfcbf9d539379 я публиковал
ссылку на короткие видеоуроки от Xiph.org, а также там есть отдельное
видео как-раз про прямоугольнички и синусоиды. Прямоугольнички -- по
сути это просто другой способ представления данных, а не тот
электрический сигнал который подаётся (да и нельзя такой сформировать).
И там на осциллографах в видео показывают что эти два отсчёта идеально
передадут оригинальную синусоиду. Теорема Котельникова как-раз и говорит
что этих отсчётов достаточно. Буквально достаточно чтобы передать
информацию.
А большие частоты дискретизации нужны для обработки звука, чтобы при его
изменении терялось из-за округления как можно меньше информации. Особенно
важна глубина квантования. Но для конечного результата, CD более чем за
глаза достаточно.