Переводчик
Последние две пятницы без какого-либо уведомления в Google Cloud блокировали аккаунт моей компании SSLMate. Впервые подобное произошло в 2024 году, тоже без какого-либо предупреждения. Но сегодня я хочу не столько предупредить вас о рисках использования платформы Google Cloud, сколько поведать о вынужденных компромиссах между снижением безопасности и удобством работы, вызванных своенравной политикой Google.
Я уже более десяти лет веду собственные дотфайлы и за это время написал множество скриптов оболочки. В этой статье я решил поделиться с вами теми из них, которые сам применяю регулярно.
Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.
Эта память не используется, не выделяется, она просто утекает. Простецкое приложение калькулятора страдает большей утечкой памяти, чем компьютеры десятилетие назад.
Случись такое в 2000-х, это бы привело к внесению срочных патчей и служебной проверке. Сегодня же это лишь очередной баг-репорт в очереди.
Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.
Если вы уже давно знакомы с Backblaze (особенно, если следите за обзорами Drive Stats), то наверняка читали наши обсуждения кривой отказов. В статье «Drive Failure Over Time: The Bathtub Curve Is Leaking» мы писали о том, как проверяли истинность старого инженерного принципа, гласящего, что сбои в работе привода, представленные в виде временного графика, демонстрируют предсказуемую U-образную кривую, иначе называемую кривая «ванны».
Но тест этого не подтвердил. В результате анализа нашей коллекции приводов были зафиксированы всплески и плато, которые никак не вписывались в предсказуемый паттерн. Теперь, спустя 13 лет непрерывного сбора данных, удалось получить более ясную картину, но и более странную.
И «ванна» в этом случае не просто «потекла» (отсылка к leak в названии вышеупомянутой статьи, — прим. пер.), её форма больше напоминает бордюр при входе в душевую кабину. Складная история о том, что вначале идут сбои, а потом спокойный средний период с плавным повышением отказов, больше не вписываются в реалии жизни наших приводов. Они становятся лучше. Говоря точнее, датасет Drive Stats указывает на повышение их качественных показателей конкретно в дата-центрах.
Давайте же посмотрим, как выглядит полученная нами кривая отказов, и как она соотносится с прежними поколениями анализа.
Если коротко, то жёсткие диски становятся лучше.
(Перевод моего выступления на P.I.W.O в июне, слегка подчищенный и приближенный к формату блога).
…звучит как-то не очень. Я сделала все эти слайды в Inkscape с ПК под управлением KDE Linux, плюс я регулярно пользуюсь Firefox. Но это всего лишь я. А что насчёт вас? Вы используете свободное ПО? Поднимите руки! [в аудитории поднимаются руки] Конечно же! Что за чепуха, «Свободное ПО не победило». Кто-то подменил мои слайды… Эй, ведущий конференции!
Ведущий: В другом каталоге.
[Перехожу в каталог с названием другой каталог и открываю файл твои слайды тупица.pdf]
Вот они мои слайды.
Всех приветствую, меня зовут Дорота, и сегодня я буду говорить о том, как …
В последние годы я много времени уделял изучению исходного кода Linux, стараясь лучше понять внутренний механизм работы компьютеров. В какой-то момент я начал писать локальные патчи для исправления проблем с оборудованием своих ПК и в итоге решил попробовать отправить один из них в апстрим, чтобы непосредственно познакомиться с процессом разработки ядра.
Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:
«Есть такая архитектура, в которой несколько сетевых или веб-протоколов собираются воедино для создания всемирной системы, где приложения (десктопные или веб) способны работать поверх уровня стандартного хранилища, предоставляющего возможность чтения/записи.
Ключевые моменты здесь в том, что главные участники (пользователи) и группы идентифицируются по URI, то есть получаются глобальными, и управление доступом к элементам хранилища выполняется с использованием этих глобальных идентификаторов. В итоге хранилище становится общедоступным ресурсом, независимым от использующих его приложений».
Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.
Ещё одну схожую по духу концепцию в то же время предлагали разработчики Opera, которые хотели «встроить в ваш браузер веб-сервер».
И если Opera Unite так и не обрела полноценную жизнь, на предложенную Тимом спецификацию обратили пристальное внимание через несколько лет, когда сменившие один другой кризисы конфиденциальности явно указали на необходимость повышения степени независимости и контроля со стороны пользователей в веб-среде.
Технический вкус — это не то же самое, что технический навык. Вы можете быть технически подкованы, но иметь плохой технический вкус и наоборот. Как и любой вкус в принципе, технический вкус зачастую не зависит от наличия фактического навыка. Вы же можете отличить хорошую еду от плохой, не умея готовить? То же самое с ПО — вы вполне способны понять, нравится ли оно вам, не имея возможности его создать. И если технические навыки можно наработать через усердное изучение и повторение, то хороший вкус вырабатывается менее очевидным путём.
Это история о том, как я превратил свой старый iPhone 8 в OCR-сервер на солнечных батареях, используя фреймворк Apple и зарядную станцию EcoFlow River 2 Pro. Он месяцами напролёт работает в режиме 24/7, обрабатывая тысячи изображений на полностью автономном питании.
За год с лишним мой сервер обработал 83 418 запросов на распознавание текста (OCR) и 48 ГБ изображений, используя только фреймворк Apple Vision и возобновляемую энергию. Большинство людей после апгрейда закидывают свои старые iPhone в ящик. Но не я. Я превратил свой телефон в сервер, который экономит мои деньги, работая полностью автономно.
Мог ли я просто запустить этот сервер на своём маке, как нормальный человек? Конечно же. Но разве это весело?
Занимаясь проектированием систем ПО, идите самым простым путём из возможных.
Причём эту рекомендацию можно применять на удивление широко. Я искренне верю, что так можно делать всегда. Эта техника подходит для исправления багов, обслуживания имеющихся систем и проектирования новых.
Многие инженеры, продумывая дизайн системы, представляют себе некий её «идеал»: что-то стройное, практически бесконечно масштабируемое, удобно распространяемое и так далее. Я же считаю, что это абсолютно ошибочный подход к проектированию ПО. Напротив, нужно вложить всё это время в глубокий анализ имеющейся системы, а затем реализовать простейшее рабочее решение.
Когда я впервые узнал о кодировке UTF-8, то был поражён её продуманностью и структурой. Тем, как изящно её авторам удалось выразить миллионы символов разных языков и письменностей, параллельно сохранив обратную совместимость с ASCII.
В UTF-8 используется 32 бита, а в старой доброй ASCII — 7 бит. Но UTF-8 выстроена так, чтобы:
- Любой файл в кодировке ASCII являлся валидным файлом UTF-8.
- Любой файл в кодировке UTF-8, имеющий только символы ASCII, также являлся валидным файлом ASCII.
Спроектировать систему, способную масштабироваться на миллионы символов и сохранить совместимость со старыми стандартами, использующими всего 128 символов — это гениально.
В этой статье я расскажу о том, что происходит внутри ядра Linux, когда процесс вызывает execve(), как ядро подготавливает стек и как затем передаёт управление пользовательскому процессу для выполнения.
Изучил я этот механизм, когда разрабатывал Zapper — инструмент Linux, удаляющий все параметры командной строки из любого процесса без прав root.
В качестве одного из своих увлечений я помогаю людям восстанавливать данные со старых ленточных кассет, например QIC-80, которые в 90-е годы часто применялись для резервного копирования. Ими пользовались отдельные люди, компании, операторы досок объявлений и не только. К ленточным кассетам я испытываю очень тёплые чувства. Есть нечто особое в том тактильном ощущении, которое возникает, когда держишь эту кассету в руках. Нечто такое, что делает сам процесс её использования приятным несмотря на все огрехи дизайна, которыми славилась технология QIC. Причём, если вникнуть в процесс и воссоздать все необходимые условия, то данные на этих лентах, даже спустя столько времени, вполне можно восстановить.
Наконец, настал этот момент, и я решился написать статью. Давно хотел, но как-то не хватало мотивации. А ведь, знаете, как говорят: «гнев — лучший мотиватор». Есть же такое выражение?
Предыстория
Я приглашаю вас в путешествие, но сначала нужно расставить декорации. Представьте, что вы работаете в некой компании X, и один из ваших сервисов на Next.js крякнулся. Ну и поскольку это Next.js, то мы понятия не имеем, что конкретно произошло, так как логирование процессов по умолчанию включено только при разработке.
И теперь перед нами квест — найти и настроить механизм логирования для продакшена. Будет нелегко, но нам как бы не привыкать.
Недавно я столкнулся с проблемой выхода из строя трёх новеньких аккумуляторов Ryobi. Тогда мне стало интересно, что послужило причиной. В итоге я погрузился в эту кроличью нору довольно глубоко – покупал десятки нерабочих аккумуляторов на eBay, реверсил печатную плату и документировал все этапы ремонта.
В этой статье я расскажу обо всём, чему научился, и дам подробные инструкции, которые помогут вам вернуть к жизни свои батареи. Среди всех режимов отказа, в которых мои аккумуляторы выходили из строя, один оказался особенно интересен, и я даже снял по нему подробное видео. Далее я подробно расскажу о нём и других, более очевидных режимах.
Я уже больше десяти лет критикую Go, о чём высказывался в своих предыдущих статьях «Why Go is not my favourite language» и «Go programs are not portable».
Описанные в них проблемы языка бесят меня всё больше, и в основном потому, что их явно можно было избежать. Мир знавал решения и получше, но Go почему-то состряпали именно таким.
Те, кто читал мои прежние статьи, встретят здесь частичные повторы, так что заранее прошу меня за них простить.
В этой статье я поясню, как все эти принципы сочетаются, и покажу примеры использования их комбинации.
Разработчики Chrome, наконец, урезали поддержку лучшего блокировщика рекламы, uBlock Origin, и теперь популярность моего любимчика Firefox снова растёт1. Так что здесь я постараюсь убедить вас перейти на этот браузер и покажу, как его использовать.
Политика найма в большинстве компаний оставляет желать лучшего. Они просто тратят своё и наше время (я как-то проходил собеседование из 9 этапов!). Они охотятся на передовых программистов и при этом даже не могут отличить реальных людей от LLM. Короче, в манибол они явно не играют.
Для соискателей картина тоже выглядит тоскливо. Некоторые из лучших знакомых мне программистов (среди которых мейнтейнеры компилятора Rust) не могут найти работу, так как теряются под воздействием стрессовых факторов собеседования. Одному такому человеку, который уже более 4 лет работает с Haskell и более 2 лет — с Rust, рекрутёр прямо сказал, что он «не технарь». Плюсом ко всему компании могут неделями, а порой и месяцами мурыжить людей, не давая понять, приняли их на работу или нет.
В этой статье я буду говорить о том, почему процесс найма столь сложен, в чём недостатки современных подходов, и как должен выглядеть его более эффективный механизм. Естественно, моя задача в том, чтобы моих друзей приняли на работу. Если же высказанные мной идеи у вас отзовутся, напишите мне.
В этой статье я коротко опишу один приём, который помогает мне писать код быстрее и с меньшим числом ошибок. Я говорю «приём», но по факту это просто практика, которой я начал следовать с опытом, сам того не замечая.
Когда вы работаете над чем-то сложным, формируйте в уме некое подтверждение, что ваш код будет делать именно то, что вам нужно. Звучит вроде просто, но на деле всё оказывается сложнее. Чтобы начать делать это «на лету», не прерывая рабочий поток, потребуется упорная практика. Зато, когда вы освоите эту технику, то удивитесь, насколько чаще ваш код будет полноценно работать с первой или второй попытки. Невероятно впечатляет.
Добиться этого можно по-разному, и я не хочу давать какие-то категоричные рекомендации. Просто приведу несколько примеров тех вещей, о которых я сам рассуждаю «на лету», чтобы вы могли сформировать общее представление.