В мае я кидал пост о том, что Hunted Labs обнаружили в крупных проектах Go-шный пакет разрабатывающийся ВК
https://xn--r1a.website/tech_b0lt_Genona/5315

Теперь ещё одно "открытие" от них же

Минобороны США использует открытую утилиту fast-glob разработчика из РФ, автор ответил на вопросы безопасности проекта
https://habr.com/ru/news/941484/

По информации иностранных СМИ (The Register, Hunted Labs), в информационных системах Министерства обороны США активно используется открытая утилита fast‑glob (https://www.npmjs.com/package/fast-glob) от разработчика из РФ Дениса Малиночкина (mrmlnc), который работает в «Яндексе».

fast‑glob — это очень быстрая и эффективная библиотека для Node.js, которая разрабатывается с 2016 года. Она широко используется в тысячах проектов, включая более 30 систем Министерства обороны США.

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

Соучредитель Hunted Labs Хейден Смит заявил, что подобные проекты вызывают беспокойство. «Каждый фрагмент кода в таких проектах не обязательно попадает под подозрение, но популярные пакеты, не находящиеся под внешним контролем, легко могут быть скомпрометированы. В целом, сообщество разработчиков ПО с открытым исходным кодом должно уделять больше внимания этому риску и минимизировать его», — заявил Смит.

Ответ Малиночкина на исследование и подозрения Hunted Labs:

«Проект fast‑glob — популярное решение для поиска файлов по шаблонам в файловой системе. Более 7 лет (с 2016 года) я разрабатываю и поддерживаю этот проект самостоятельно. Проект был начат до моего начала работы в «Яндексе», и его разработка или поддержка никогда не входили в мои профессиональные обязанности в компании. Я выпустил этот проект с открытым исходным кодом ещё в 2016 году, полагая, что он может быть полезен разработчикам, и рад, что так получилось.
. . .
Я поддерживаю проект в одиночку, поскольку за эти годы сообщество не выразило потребности в более активном участии. Это типично для решений инфраструктурного уровня, с которыми пользователи не взаимодействуют напрямую. Я всегда открыт для вклада сообщества. Также хотел бы ещё раз подчеркнуть, что как исходный код, так и distributed package полностью открыты и доступны для проверки потенциальными пользователями.

Отвечая на ваш вопрос: никто никогда не просил меня манипулировать fast‑glob, вносить скрытые изменения в проект или собирать и делиться системными данными. Я считаю, что открытый исходный код основан на доверии и разнообразии»

Оригинал
Not So Fast and Furious: Popping Fast-Glob’s Hood
https://huntedlabs.com/popping-fast-globs-hood/

#prog #article

Faster Rust builds on Mac

Did you know that macOS has a secret setting that can make Rust builds faster? It can also make Rust tests faster (sometimes massively so). It probably even has similar effects for other compiled languages such as C, C++, Go, and Swift. It sounds crazy, but read on…

Nicholas Nethercote заметил, что на Mac компиляция одного Rust-проекта была подозрительно долгой. Замеры времени компиляции через cargo показали, что очень долго исполняются билд-скрипты, причём каждый следующий дольше предыдущего. Как оказалась, это антивирусная фича MacOS (называется XProtect), которая сканирует исполняемые файлы на признаки malware при первом запуске. Билд-скрипты компилируются и исполняются каждый раз заново при компиляции, поэтому постоянно страдают от этих задержек. Замедление же объясняется тем, что процесс, который сканирует исполняемые файлы, однопоточный.

You can avoid these scans by adding Terminal (or any alternative terminal app you are using, such as iTerm) as a “developer tool” in System Settings. See these docs for details.

<...>

Please note that if you do this you are disabling an OS security feature. You should not do it unless you are comfortable with the potential speed/security trade-off.

По очевидным причинам это ускоряет и cargo run, и cargo test (особенно для доктестов до edition 2024, каждый из которых компилируется в отдельный бинарник).

The status quo is that this behaviour is documented in a few obscure places and 99%+ of Mac users are unaware. Fortunately, Mads [Marquart] has a draft PR for Cargo that detects if XProtect is enabled and issues a warning to the user explaining its impact and how to disable it.

Из забавного: отключение XProtect снизило для Mads Marquart время для прогона всех UI-тестов rustc (около 4000 исполняемых файлов) с 9 мин 42 с до 3 мин 33 с.

В контексте прошлого поста в личку принесли вакансию от ВК https://team.vk.company/vacancy/41375/

> Наш основной проект — создание личного кабинета, позволяющего удобно получать необходимую информацию и оформлять кадровые или финансовые заявки.

И там среди требований

> Будет плюсом
> Владение ABAP

ABAP это язык программирования от SAP

Так что ВК тоже пилит замену SAP 🌝

UPD
В личке подсказывают, что могут пилить ещё какую-то интеграцию.

16–17 сентября планирую быть на DevOops - https://devoops.ru/

В этом году без доклада 🌝

Если кто хочет пересечься, то пишите в комменты или личку

Смотрел тут на очередное веб-приложение, там в ряд — текстовое поле, две кнопки, выпадайка. Все примерно одного дизайна (серая однопиксельная рамка, белый фон) и примерно одного размера. Примерно, потому что не точно — очевидно они должны были быть одинаковыми, но не смогли.

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

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

Казалось бы, как это бы выглядело в идеальном случае? Пришел программист, сказал height = 36px, ну может еще добавил, что текст надо по центру. И все. Работа сделана. Примерно так было в условном Дельфи, который до сих пор все вспоминают с теплотой. Секрет в том, что на этом и надо было бы остановиться. Но мы давно промчались мимо этой идеальной точки и теперь ее не видно даже в зеркале заднего вида.

Что же произошло вместо этого? У вычисления высоты появились правила. Нельзя теперь просто указать высоту, она вычисляется, с одной стороны, от размера шрифта снизу, а с другой от контейнера сверху. Еще бордер там добавится, маргин какой-нибудь схлопнется, ну вы поняли. Очень непрозрачные правила, а главное — их очень много. Причем каждое правило, когда добавляли, наверняка что-то упрощало. А теперь все вместе они стали просто непозноваемыми. Почему прямоугольник с заданной высотой с текстом отличается от прямоугольника с такой же высотой но без текста внутри? Поди разбери. Работает как-то и бог с ним.

Туда же эпидемия с центрированием. Раньше были шутки, что на вебе сложно вертикально центрировать div. Сейчас этот вопрос вроде бы порешали, div центрировать можно, а вот с текстом все еще проблемы. Опять же, потому что правила совершенно идиотские, никто не знает, как условный line-height работает. На весь интернет может быть одна статья про него, где человек разобрался, а остальные просто на глазок подгоняют, я уверен. И дизайнеры шрифтов, кстати, тут вообще не помогают.

Добавьте к этим идиотским правилам центрирования текста идиотскую моду на шрифты с иконками и вот мы в абсурдной ситуации, когда прямоугольник никто не может поставить ровно в другой прямоугольник.

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

Это все удивительная демонстрация, как на большом масштабе «умные» декларативные правила, которые должны помогать, скорее мешают, потому что их поведение сложно предсказать. И это не только веба касается, со SwiftUI та же беда — хотели сделать проще и высокоуровневее, а оказалось, что и неудобно, и ошибиться в разы легче, чем когда были простые и деревянные прямоугольники, которые ты ставил куда нужно.

Короче, сложных «умных» правил быть не должно. Нужно делать минимально необходимый минимум, но надежный, предсказуемый и познаваемый (т.е. должен в одну голову помещаться). Тогда это фундамент, на котором можно что-то строить. А так болото какое-то. Жидкий грунт.

[Видео] Концепт Flipper OS — операционной системы для Flipper One

Главные тезисы:

• Неизменный root

• Вместе с системой есть пачка предустановленных профилей системы с разными конфигами

• Юзер работает только внутри профилей. Все изменения профиля записываются поверх, как overlay

• Внутри профиля юзер может делать что угодно и писать в root

В этой схеме есть много непонятных мест. Буду рад любым мнениям.

PDF-файл презентации на видео: flipper_os_concept.pdf