Jedy Channel

​​Wont fix Ахахахахаха, я в полном восторге. Друзья мои, вам не кажется, что, если у вас в бэклоге пицот открытых багов - что-то не тово с вашей методологией разработки и что-то не тово с вашим менеджментом, а?! При этом баги втихушку и полностью автоматически переползают в этот самый вонт фикс? Нет? Ничего ненормального не видите? В коммерческом ПО, за которое бапки берете? То есть, это абсолютно нормальная ситуация, да? Я тут хочу припомнить еще одно ПО. СПО. Которому тридцатник в обед - оно ровесник линя - и там тоже по полтысячи открытых багов висят - нет, не годами! - десятилетиями, Карл. Причем где-то половина из них - assertion failed - а скажите-ка мне, как ассерты вообще попадают в продакшен билды, м? Багрепорты со стектрейсами висят по 15-20 лет в максимуме. Причем там нехилое такое соопчество. И даже отдел QA есть, не поверите. Ну? Попытаетесь меня убедить, что СПО лучше чем проприетарь? Я, однако, совершенно о другом. Может, пора поменять методологию разработки и девок в борделе, а? Раз километровый бэклог считается нормасом и даже автоматится? Нет? Вы так не считаете?

Раньше трава была зеленее Время воскресных очешуительных историй. Вообще, в релиз ноутах должна быть совсем не история коммитов. Вы посмотрите на подобные документы, написанные до тех времен, когда чужие стеной пошли вайтишечку. Просто для интереса. Во-первых, релиз ноуты все же пишутся ручками. В них пишут верхнеуровневые изменения - что поменялось в архитектуре, в функционале - причем понятным, человеческим языком. Как вы думаете, когда у вас закрытый код, к примеру - ну, коммерческий - что дадут ваши описания коммитов простому смертному? А читают релиз ноуты совсем не архитекторы, это часть комплекта открытой документации. На минуточку. Во-вторых, а вам не кажется, что генеративная документация - это и не документация вовсе, а работа на отъебись, что называется? Да и не работа это вовсе. И гордиться тут ну вообще нечем. Вот сами подумайте. Ченджлоги у вас - история коммитов, ничего не говорящая никому, кроме девов. Релиз ноуты - описания коммитов, ничего не говорящие никому, кроме девов. Кому нужна такая работа? Тимлиду? KPI считать? Ну и? Все знают, что я люблю приводить в пример документацию китов - написанную инженерами для инженеров и техписами для пользователей. Подробную, исчерпывающую, вменяемую. Я и сам так же стараюсь ее писать. Ручками. Вдумчиво. С расчетом на то, что ее будут читать. И что? Знаете, что мне на днях заявили? "Твоя документация выглядит как будто ее студент писал". А как теперь надо? В виде комиксов, что ли? Серьезно, Карл? Выросло поколение, которое традиционную документацию видит как набор иероглифов, потому что дислексия? Ну так с такой инвалидностью вали ВОН из индустрии, которая, тащемта, все еще считается инженерией и заточена под тексты. Комиксов рисовать не буду принципиально. И генерировать такую важную часть ПО не буду тем более. PS. Я понимаю, что День Дегенерата настал и он теперь с нами навсегда. Но - нет, Гэри. Нет. Учитесь читать и понимать написанное. И связно излагать информацию. В противном случае - Эверест недоставленных пицц, он ждет своих героев.

Цитата дня Вы с деньгами никогда не работали? Большинство клиентов не устраивает падение сервиса, считающего деньги (биллинги всякие) даже раз в год. Нельзя, нельзя выключать своп у любой организации которая не песочница для детей. Люди очень волнуются, даже когда посты пропадают на форуме.

​​Добро пожаловать в реальный мир, чуваки Вы правда думали, что ваша GPL кого-нибудь тово, чпокает? Прав тот, у кого больше прав. Пальчиком грозить вы можете сколько угодно. "Ичо, ичо ты мне сделаешь?!" Ичо, ичо ты им сделаешь? Справедливости для - разве я не говорил, что единственным достоинством опенсурца является сладкое слово "халява"? Добро пожаловать в реальный мир. Пойдите, насадите их в Лондонском Суде - и выиграйте дело, что самое главное. Кстати, вы тоже ведь линукс не покупали, верно? Правильно, э?

"Ну не нравишься ты мне!" А вообще, чума на оба ваших дома. В сортах говна, как говаривал Кураев... И то и другое - одно и то же, различаются лишь названия. Поэтому я пользуюсь Файрфоксом. Из принципа. А если куда-то не пускает (типа егова) - то разгугленый хромиум.

Цитата дня Большой процент так называемых «экспертов» сегодня знают только, как использовать какой-нибудь хайповый инструмент, но они ничего не понимают в том, как все работает на более глубоком уровне.

Просто оставлю это здесь 😂🐈

​​День Дегенерата настал Я говорил, что бузинесс туп, глуп и реактивен?! Всегда говорил. Бузинесс туп, глуп и насквозь реактивен. Долго сказочка сладкая сказывалась, но вот она закончилась и просто время платить по счетам. Возьми все, что хочешь и заплати положенную цену. Это прописная истина и трюизм - а вы что, на берегу, не знали, да, что так и произойдет, причем неизбежно? Д - дальновидность. Как говорит один мой знакомый, "По грехам".

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

​​Добби свободен Время воскресных очешуительных историй. We need to go deeper с утечками памяти, бо разработчики, как практика показывает, неважно себе представляют подкапотное поведение. Итак, что происходит, когда область памяти по указателю void* освобожается вызовом free()? По факту, аллокатор (системный, кастомный или ОС) просто переносит этот указатель в список свободных внутри себя (и отмечает это в своих метаданных). Память не зануляется, указатель не разадресовывается и не обнуляется автоматически. Таким образом, указатель не просто остается валидным. Он так и продолжает смотреть на чанк, который уже возвращен в свободные, но, часто, все еще содержит прежние данные. Это стандартное поведение. Зануление указателя (чтобы попытка повторного обращения - грубая ошибка сама по себе - привела к сегфолту) - это прерогатива программиста. Ни ОС, ни аллокатор не делают этого автоматически - для скорости и потому, что существует calloc() с memset() внутри. Так вот. Если по какой-то причине программа занулит указатель раньше, чем чанк будет помечен вызовом free() как свободный, он остается во владении программы, но более недоступен - мы зачистили указатель. И освободить его до конца работы программы мы уже не можем, это сделает лишь ОС, прибирая мусор при том или ином завершении программы. Именно это и называется утечкой памяти - это и ничто другое. Заметим в скобках, что мы говорим об относительно простых типах. Если по указателю содержится нетривиальный тип - что-то кроме, скажем, массива указателей, которые смотрят на структуры, которыми владеет кто-то другой - то необходим нетривиальный деструктор, последовательно, шаг за шагом, освобождающий субструктуры и зануляющий их субординатные указатели. Иначе утечка произойдет незаметно для программиста. Ну и немного баден-бадена касательно инициализации. malloc() - и он вызывается под капотом выражения new и оператора new - память не инициализирует, как вы помните. Выражение new, однако же, позволяет инициализировать POD типы, а также некоторые типы STL (массивы, например) указанием пустых скобок () или {} (см.стандарт C++) при вызове выражения new. Надеюсь, стало немного понятнее про утечки. )))

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

​​RTFM Да написание документации - это фуйня. Вот ее чтение... Последние несколько лет мое воображение потрясает патологическая неспособность специалистов даже не то, что понимать - а просто читать документацию. Даже наличествующую. Даже хорошую. Вообще. Никак. В самом лучшем случае - откроют, если ничего не помогло; кусочно, прочитали отрывок, в который носом ткнули - да и ладно. Зачем ее читать?! Вон, ТП есть. Если что - процитируют и пальцем ткнут. Как говорится, "Нафига география? Есть же извозчики". Результат немного предсказуем. "Ребят, я вообще ни бум-бум в вашей системе, подскажите, что сделать и какие команды в точности нужно выполнить?" На базовых, простейших, элементарных вещах. Дальше - больше. Утрачена способность элементарно гуглить. Вломмммм. А пусть за нас GPT гуглит. Мне вот интересно, фуль вы будете делать, когда он вам нагуглит, что банку с нитроглицерином - "Взрывается при сотрясении" - можно и нужно трясти.

​​Язык мой - враг мой Время воскресных очешуительных историй. Одним из самых отвратительных свойств C++ является способность компилировать большинство конструкций C. В моей практике был случай, когда пару лет пришлось мучительно ломать башку, как добиться, чтобы безупречно собирающаяся компилятором библиотека - без единого варнинга со всеми тапками в пол, -Wall, -Wextra и -Wpedantic - работала без крэшей. Есть такая штука в сишечке, как юнион (union). Так вот. Пока вы используете его с тривиальными POD-типами, имеющими тривиальные конструкторы - все ча-ча-ча. Кресты его видят, понимают, компилируют и оно работает. Хоть анонимный union, хоть неанонимный. Однако. Если ваш union сдержит нетривиальный тип, который, к тому же, доступен по указателю (мемберы юниона - это указатели на структуры, да) - у вас не получится позвать нетривиальный конструктор этого типа. Да-да, я читал ту статью на SO, где предлагается конструктор в юнион написать и позвать его явно. Во-первых, это не помогает в случае нетривиального динамического субтипа. Во-вторых, вызов конструктора оператором new в конструкторе супертипа - компилируется, да. Но в рантайме член юниона остается неаллоцированным, что и приведет вас прямо к радостным рандомным крэшам в рантайме. Что означает практически UB. Вы скажете - агааааааааа, есть же std::variant! Ну, для начала, он есть начиная с С++17. Что делать тем, кто должен работать на C++11 - кроме апгрейдов - неясно, да? Во-вторых, эти нехилая такая оберточка поверх сишного юниона, с кучей оверхеда - как часто бывает в синтаксическом сахаре - и это означает, помимо всего прочего, кучу писанины на уровне исходников - вы ж видели спецификации std::variant? В целом, картинка достаточно нерадостная, учитывая огромное количество кода Си с классами. И это опять возвращает нас к исходной позиции - это на самом деле ужасно, что кресты позволяют большинство конструкций Си компилировать. На практике, этого следует избегать, как чумы. Один мой друг прямо настаивал в свое время "Пишем на чистых крестах, никакого Си!" - и был абсолютно прав. Либо вы сишник - либо крестовик. Любая попытка как-либо комбинировать два настолько концептуально разных языка - чревата, по моему личному опыту, а равно и по опыту других. PS. А начиналось-то все невинно, с сишных кастов в крестах, да?

​​Это страшное слово "аптайм" Я много лет с интересом наблюдаю, как все остальные долго и мучительно пытаются дотумкать до того, до чего FreeBSD дотумкали давным-давно. Вечная битва бобра с ослом. Собственно, откуда ноги растут у желания поскорее освободить память и вернуть ее ОС, я прекрасно понимаю - когда-то, во времена Она, когда отцы-основатели были молодыми и симпатичными, а оперативная память стоила как крыло от боинга, не было задачи важнее. Сейчас все трындят о том, что оператива стоит как лопата дерьма. И продолжают в том же духе. Почему это фигово и почему игроделы с их аренами совершенно правы? Потому, что фрагментация. Если заглянуть под ковер, на уровень ОС, под крышку mmap(), то можно увидеть, как операционка адово фрагментирует пространство виртуальной памяти. А прорвавшиеся к срулю девелуперы еще и начисто отрубают своп. Ненуачо, рестарт-инжиниринг же существует. А в линуксе еще и костылище в виде дефрагментора. Как я упоминал выше, наиболее умно поступили ребята из FreeBSD. Они справедливо считают, что отдавать память ОС до завершения работы программы, в общем, в 21 веке совершенно незачем. Потому, что фрагментация много хуже. В плане аптайма. Конечно, во времена кубернетес оно, может быть, и пофигу. Подумаешь, рестарт, чотаковата. Мы давно меряемся временем загрузки ОС с нуля. Хочу заметить также вот что. Когда фрагентация началась - не если, а когда - время выполнения malloc() становится сильно непредсказуемым. Надо пробежаться по всему пространству и найти фрагмент, где можно выполнить умещающийся mmap(). Вам все еще пофигу? Помнится, миллисекундами лейтенси кто-то любит меряться. В общем и целом, игроделы, тащемта, не идиоты. Если вы посмотрите на сорцы аллокаторов, то увидите, что кое-кто начал частично понимать суть и глубину проблемы и арены-таки создавать. К сожалению, допёрло совсем не до всех и не везде. Ну и частичное решение в данном конкретном случае принципиально ничего не меняет. Как была фрагментация, так и осталась. Разве что чуть замедлилась. Не в порядке подачи ценных идей, а в виде констатации факта - а FreeBSD, в общем, имеет аптаймы на порядки выше, чем остальные. Именно поэтому. Но в ИТ, как известно, никогда не побеждают лучшие парни.

Просто оставлю это здесь, а то некоторые считают, что я выдумываю. Что ж, как заплачено - так и зафуячено. Надо ли удивляться тому очевидному факту, что самая распространенная халявная ось на планете вовсе не является техническим совершенством?

​​Верхушка айсберга Время воскресных очешуительных историй. Хорошая статья, которая, как "Титаник", лишь поверхностно чаряпнула айсберг потокового выполнения, плавающий в Атлантике. Так получилось, что мне довелось много лет заниматься параллельным процессингом и тредовыми вычислениями. Постулаты, с которыми я согласен - и они подтверждены практикой - пребывание в юзерспейсе дешевле в плане накладных расходов и утилизации процессорных ядер. Простым языком - мьютексы дорогие. Второе. Треды - это обычно не о лейтенси. Если вы хотите получить соизмеримую с однопотоком латентность тред-пула, к примеру, вам придется принимать целый ряд мер архитектурного порядка для достижения этой цели. Как-то - фиксированное число воркеров (и - да, один поток на физическое ядро), множество очередей (MPMC) фиксированной длины (причем очереди желательны неблокирующие, что хотите, то и делайте), job stealing - причем его надо очень вдумчиво реализовывать. Все вместе означает весьма тщательное программирование с целью минимизации паразитной работы и оверхеда. И вот что еще важно - это, наверное, самое важное - минимизация общих, совместно используемых данных. Это бывает очень непросто достичь, например, делая отдельные TLS (thread local storage). Причем следует иметь в виду, что реализация TLS в крестах, например, достаточно медленная и на реально высоких скоростях следует принимать ряд специальных мер по ускорению - вплоть до частично или полностью своей собственной реализации TLS на основе pthreads. Отдельная проблема - тредовый IO. IO bound задачи характерны тем, что, как правило (бывают исключения) надолго блокируют ядра и воркеры, вызывая характерные всплески утилизации CPU. Причем никаким разумным образом эти всплески невозможно уменьшить. Имеющиеся реализации AIO на тредах проблемны в плане утилизации ресурсов, фрагментации памяти и крайне затруднительна реализаци тредовой записи. Для тредовой записи нужны особые архитектурные решения, наподобие партишенинга, и особая организация данных и/или совместного доступа. Что само по себе крайне непросто. Частное решение задачи, связанной одновременно с IO и CPU-bound тредами, было выполнено здесь. Реализация нацелена на решение всех вышеперечисленных задач, с одновременной постановкой задачи "Пул не является постоянно нагруженным и должен спать, если задач нет, при этом мгновенно просыпаться при появлении заданий в очередях". Практическое решение, использующее данную архитектуру, было применено в этом приложении и позволило достичь экстремально высокой масштабируемости в рамках конечного числа процессорных ядер при минимальной латентности и пропускной способности в десятки и сотни тысяч RPS. Хочу заметить, что R&D, позволивший получить такой результат, занял свыше 2500 человеко-часов. Finally, подобные архитектурные выводы, как правило, подкреплены солидной исследовательской базой и к ним следует, вообще говоря, прислушиваться и учитывать их в проектировании ПО. Особенно если мы говорим про тредовые многоядерники.

"Долго шел!" Он не просто вышел, его натуралы уже давно раскатали, а для ЛГБТшников в роллингах в репах сборки появились. Давайте душнить!!!!!!11111 Я посейчас нахожу OpenSSH шестых версий местами ) Ненуачо, обновляться не нать, особенно в таких сервисах, которые, к тому же, торчат жопами в инет да еще и с парольным входом - ага, сейчас, в 2023м. Как бы вам помягше-то сказать...Долго шел!

​​Самый мощный инструмент находится между ушами Весьма часто за утечку памяти принимают то, что ей, вообще говоря, не является. В моей практике очень давно был один апокрифический случай, когда я в цикле просто память не освобождал - как результат, очень быстро была выжрана вся виртуальная память до байта и система грохнулась в панику. К слову, с точки зрения производительности, аллоцировать и деаллоцировать в цикле - очень фиговая идея, учитывая скорость аллокаторов ОС общего назначения (и не только общего, к слову). Есть еще один пример, когда утечка - совсем не утечка. Например, у вас есть очередь или очереди. И вот на другом конце очереди что-то затупило. И тут очереди начинают заполняться, стремительно исчерпывая память. Это, разумеется, не утечка. Но я лично был свидетелем, как подобное поведение годами считали утечкой и гонялись за призраком на полном серьезе. Причем так и не нашли и побороли посредством рестарт-инжиниринга. Как обычно, в общем. Что я хочу сказать. Как и в тюнинге, одна из самых сложных тут вещей - диагностика. И, разумеется, до плохого можно и не доводить, если просто тщательно писать код. Ну и, по возможности, не пренебрегать статическим анализом.

​​"Послушайте, а когда же вы думаете?" Знаменитая цитата из Резерфорда просто напрашивается. Это вы, золотые мои серебряные, никогда R&D, наверное, не занимались. Там обдумывание может и месяцы занять как здрасьте. Особенно когда вы на неизвестной территории находитесь. И делаете что-то, чего никто до вас не делал. Количеством строк в единицу времени уже измеряли KPI, ага. Теперь будем количеством коммитов меряться. Ну, стоит ли удивляться тогда, например, вот этому? Или количеству выдаваемого на гора говнокода? Хотя на галерах, конечно, еще и не то бывает, у крабов. Что я могу сказать... продолжайте в том же духе. А они еще что-то там про сеньоров трындят... Мозги дело такое, они бездымный порох по расписанию выдумывают с трудом, знаете ли. Хотя вот круды шлёпать, или, там, джейсончики перекладывать - оно, конечно, можно резко, как струя поноса.

Цитата дня Я понял, наконец, почему западные айтишники - тоже муйло неграмотное - называют жесткий диск, да и оптический тоже - медиумом. Он же вертится, как стол у медиумов на вызове духов. Странно, сука, почему журналистика не вертится в масс-медиа.