Я всегда думал что его там нет - ни ** ни pow() не работают, и считал его как e(l(x)*y). Сейчас заглянул в ман чтобы посмотреть как там определить кастомную функцию (чтобы задать pow в каком-нить конфиге), и случайно наткнулся на список арифметических операторов, где значком, обычно использующимся для XOR (^), оказывается обозначается возведение в степень. Правда, только в целочисленную, но в большинстве случаев другого и не надо.
Вскоре после обнаружения 18-летнего потенциального RCE было обнаружено ещё одно, CVE-2026-9256, на этот раз просуществовавшее ещё дольше — 21 год, начиная с версии 0.1.17, выпущенной в начале 2005 года. Для эксплуатации уязвимости требуется наличие в конфиге сервера директивы rewrite, у которой:
( читать дальше... )
>>> Официальное объявление F5 (f5.com)
20 мая 2026 года разработчики FreeBSD объявили об исправлении семи новых уязвимостей в системе. Не все они одинаково опасны, но есть и крайне неприятные.
( читать дальше... )
>>> FreeBSD Security Advisories (freebsd.org)
13 мая была исправлена уязвимость в популярном для нагруженных систем веб-сервере nginx: CVE-2026-42945, потенциально могущая привести к RCE. Уязвимость появилась 18 лет (2008 год) назад в версии 0.6.27.
( читать дальше... )
Информация об уязвимости была предоставлена Zhenpeng (Leo) Lin из DepthFirst. Кроме того, он же сообщил о следующих проблемах, которые тоже исправлены:
>>> Официальное объявление F5 (f5.com)
Запускаю железку, попадаю в recovery mode, /boot не смонтировалось.
Написал mount -a - смонтировалось успешно, выхожу из recovery и всё грузится дальше и работает. Ребутать для проверок больше нельзя.
В journalctl -b было такое
systemd[1]: Mounting /boot...
systemd[1]: boot.mount mount process exited, code=exited status=32
systemd[1]: Failed to mount /boot.
systemd[1]: Unit boot.mount entered failed state
Прописано в fstab через UUID. Файловая система xfs. boot на том же устройстве что и /, при этом / разумеется ещё раньше смонтирован успешно, то есть устройство не могло к тому времени ещё не найтись ядром. В dmesg ничего про это не написано, только лог успешного монтирования из моего mount -a.
Что ему не понравилось и куда системг спрятал лог неудавшегося mount-а при старте?
«i/o error» на любые действия, после перетыкания в слот есть небольшое время когда можно запустить smartctl, затем опять отваливается.
=== START OF INFORMATION SECTION ===
Device Model: SATAFIRM S11
9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 271978
271978 - враньё, разумеется.
Понятное дело, что у него что-то слетело и чинить его нецелесообразно, но в чём причины могут быть? Это признак того что он поддельный или просто неудача? Стоял практически без нагрузки с момента покупки - занято меньше 10гб из 120, запись наверно меньше мегабайта в день (а может и вообще около нуля), чтение тоже не особо большое.
Допустим, я добавлю в свою пермиссивную лицензию пункт о запрете скармливания кода LLM-обучателям (включая косвенное скармливание путём отправки кода туда, где это с большой вероятностью будет сделано автоматически). Какие негативные последствия для продукта от этого могут случиться?
Обсуждения того, что бессовестные llm-щики на всё это наплюют и всё равно украдут код в свои бредогенераторы, прошу тут не устраивать, вопрос не про это.
Уже который раз из-за рандомной фразы начинается дискуссия, которая оффтоп к обсуждаемой теме, но тем не менее вполне заслуживает быть обсуждённой в техническом разделе. Выходим дилемма или нарушать правила оффтопом или отказываться от обсуждения, оба варианта не особо приятные. Почему бы не сделать вынос ветки в новую тему?
Тема black, старый вид.
Были у меня в директории рядом с исходниками, внутри рута рабочей копии vcs, несколько скриптов тестов. Часть из них использовала внешние (по отношению к репе) данные, и поэтому я их пока не коммитил (внёс в игнор-лист), думая что закоммичу когда решу вопрос с нормальным хранением данных для них. А только что мне пришлось там же рядом, в директории с тестами (она не вся в игноре), откатить локальное изменение, и я сделал revert на всю tests/. Но в revert был баг - оно игнорировало списки игнора и откатило tests/ к состоянию репы, по факту сделав rm -Rf на всё что было заигнорировано :(
Такая вот печальная история, и мораль: даже для временного лучше всё-таки иметь хотя бы одну запасную копию.
К счастью, я ещё два года назад сделал себе утилиту Найти случайно затёртый с диска исходник и теперь тремя командами восстановил три утерянных скрипта. А вот тарболл с эталонными логами одного теста, и ещё кое-что бинарное придётся заново генерить, его так не найти.
Кто с какими сталкивался (без археологии)? Какой из современно используемого софта можно под них скомпилировать чтобы он работал, без кучи костылей? Речь про системы, которые можно представить в виде чего-то компьютеро-подобного, например пытаться запустить на них, например, хотя бы обычное /bin/cat.
Напомню, Си формально не требует 8-битных байтов. А следовательно, используя всякие int8 int16 итд - рискуем получить слом совместимости с системами, где байты например 7-битные или 10-битные (там таких типов получается не будет). Стало интересно, насколько это актуально, или можно с чистой совестью продолжать забивать на это, как я всегда делал.
Я, конечно, понимаю, что такие системы, даже если существуют, очень редки. Вопрос в том, насколько они «очень редки» или же их сейчас вообще ровно ноль.
В очередной раз увидел эту штуку в мане к procfs. Возник вопрос - почему везде дефолт 0? Это же дыра для всяческих утечек. От 1 или 2 что-то может сломаться? В фрибсд всегда настраивал сокрытие чужих процессов, и даже инсталлятор там предлагает это сделать (с некоторых пор). В линуксе же кроме абзаца в мане нигде почти не упоминается, как будто не принято.
Система FreeBSD.
Ситуация такая: входящие пакеты собираются сетевухой LRO в один большой tcp-сегмент. Дальше оно должно роутиться на другой интерфейс, в него такой большой пакет не влезает. Даже если послать назад icmp ошибку, исходный хост же не виноват в ситуации и исправить ничего не сможет. TSO на втором интерфейсе нет.
Очевидное решение - отключить LRO, но есть и нетранзитные соединения (их даже большинство), где он полезен. Какие у кого есть мысли по этому поводу?
Способов нарезать назад большой tcp-сегмент на маленькие же нет? (речь не про ip фрагментацию а перепаковать именно tcp)
Это же очень важное событие для линукса, как её можно удалять?
Заметил такую штуку. Если на входящий («in») пакет сделать fwd для смены ему next-hop (старый next-hop был локалхостом в связи с тем что dst ip локальный, новый - внешний), то при последующем проходе правил на выходе для исходящего («out») пакета интерфейсом отправки всё равно значится «lo0». Т.е. пакет можно файрволить правилом с «out xmit lo0», однако на самом деле он шлётся по указанному в первом проходе файрволла next-hop-у через соответствующий ему интерфейс.
Планирую позже посмотреть маны и исходники на этот счёт, чтобы узнать это так и задумано или баг, и если баг то отправить репорт. А пока что написал тут, вдруг кто уже знает ответ.
Меня время от времени обзывают луддитом в связи с моим осуждением некоторых современных модных ИТ-штук.
Извиняюсь за внешнюю ссылку, но нашёл интересную статью про данную тему.
Ъ:
Луддиты вовсе не воевали против машин, они и сами их использовали в своей частной работе. Данный образ (борцы против автоматизации) - карикатура на них, созданная капиталистами с целью луддитов дискредитировать в глазах общества. Оборудование они, иногда, действительно ломали, но не из-за ненависти к автоматизации, а из-за желания навредить владельцам соответствующих фабрик.
Причина недовольства такая: были ремесленники, которые делали качественную продукцию (в том числе на станках), живя при этом вполне комфортно и самостоятельно выбирая сколько и когда времени посвятить работе. Потом появились коммерсанты, которые решили производить дешёвый ширпотреб, нанимая к себе не особо квалифицированную рабочую силу на конвеер, и заставляя эту самую рабочую силу работать максимально длинными сменами. Оказалось, что народ в массах привлекается низкой ценой больше чем высоким качеством, и добросовестные ремесленники начали проигрывать конкуренцию. Идти на фабрики производить ширпотреб по 15 часов в сутки за нищенскую оплату они, разумеется, не хотели, и поэтому решили вразумлять владельцев этих фабрик чтобы те сменили политику.
То есть тут прослеживается два аспекта: 1) социалистические идеи о том что трудящиеся должны жить хорошо и не должны эксплуатироваться капиталистами, 2) противодействие скатыванию своей профессии к производству хлама. Войны же с автоматизацией среди мотивов не было, это была только идеологическая карикатура на них.
В упоминаниях, если маркдаун выбрать.
Навеяно этим опросом: Сколько максимум дисплеев, одновременно подключенных к одному компьютеру, вы регулярно используете?
Речь про личную технику, т.е. которая в собственности, а не выдана/отдана под присмотр работодателем.
>>> Результаты
Представим, что юзер открывает файл размером 10гб в редакторе кода и пролистывает хоткеем в конец. Допустим, редактор умеет корректно работать без предварительной подгрузки всего файла в память (под ответственность юзера что файл никто со стороны не испортит в неожиданное время, или пусть вообще он в read-only режиме - просмотрщик кода). Как редактор кода должен себя вести в плане подсветки синтаксиса?
В техническом плане тут всё очевидно: пока редактор не прочтёт и не распарсит все 10гб, сделать гарантированно правильную подсветку в конце он не сможет (ведь где-то в середине может быть открывание комментария, например). Вобщем-то и варианты поведения очевидны (ниже напишу), вопрос именно в том, какой их них наилучший в плане удовлетворения юзера. Допустим даже в конфиге можно выбирать эти варианты, но есть же дефолт - и он должен быть максимально не бесящим насколько это возможно.
Варианты:
1) залагать и парсить подсветку этих 10 гб, и только когда оно доделалось отлагать и нарисовать всё
2) нарисовать конец файла без подсветки, парсить её в фоне (где-нить выводить % готовности) и как закончим - нарисовать с подсветкой
3) нарисовать конец файла с черновой подсветкой, распарсенной без учёта пролистанных мимо страниц (ну, возможно ещё захватить сколько-то кбайт/строк выше верхней границы видимости), в фоне парсить нормально и как дойдёт до конца - перерисовать
4,5) варианты 2,3 но в фоне ничего не парсить и так и оставить (ведь юзер может оказаться недоволен нагрузкой на диск или на проц, из-за которых лагают другие проги)
6) каждый раз в таких случаях спрашивать у юзера хочет ли он фоновый или нефоновый парсинг (в виде попап окна) и надо ли делать предварительную неточную но быструю подсветку
| следующие → |