Такие посты я буду формировать в промежутках между лонгридами
Вас ещё можно переубедить или это уже неизбежно случится? Я бы не хотел продолжения серии — очень не нравится такой стиль изложения, когда мало информации и много эмоций.
Ну, ситуация-то, сами понимаете, такая, с огонёчком, да?
Ситуация обычная. Работа менеджмента в том и состоит, чтобы с такими справляться. Как правило, нет никакой «проблемы старожилов» (кстати, это слово так склоняется, а не как у вас в тексте), а есть другие приоритеты у руководства.
Понадобится немного модифицировать семейство системных вызовов «exec», чтобы диспетчеризация зависела от типа исполняемого файла.
Не нужно ничего модифицировать — в ядре уже имеется механизм binfmt_misc, позволяющий запускать чужеродные бинарники. Например, я использовал его вместе с qemu для сборки модулей ядра для ARM-одноплатника (очень не хотелось возиться в кросс-компиляцией).
Юзкейс «запускать исполнимые файлы Windows через Wine при помощи binfmt_misc» настолько очевиден, что приводится как пример в man binfmt.d и википедии. Это никакая не панацея, а скорее финальный штрих, которой можно сделать для удобства, когда все остальные проблемы с совместимостью уже решены.
Я вижу два возможных сценария, где это могло бы быть полезно:
Можно сразу начать вбивать следующий код, если понимаешь, что текущий уже не успеешь набрать до истечения его срока действия. Не нужно будет стирать уже набранные знаки и начинать всё заново.
Если вдруг попадётся ненормальный сайт, который не следует рекомендации стандарта TOTP принимать не только актуальный код, но и предыдущий и следующий, эта фича может выручить. Кажется, когда-то давно у меня подобное было с Госуслугами — не принимался код и всё тут. Помогло быстро ввести код в самом начале срока его действия.
Я сам не пользуюсь этой опцией, но она есть в Aegis — в другой ветке её упоминали как киллер-фичу неизвестного мне приложения Ente Auth.
Namescheap всем разослали - это "мы вас всех удалим через 24 часа."
Нисколько не хочу защищать Namecheap, но было всё-таки не так. Попросили свалить в течение недели. Формулировка в том письме (от 28 февраля) была такая:
If you hold any top-level domains with us, we ask that you transfer them to another provider by March 6, 2022. Additionally, and with immediate effect, you will no longer be able to use Namecheap Hosting, EasyWP, and Private Email with a domain provided by another registrar in zones .ru, [...]. All websites will resolve to 403 Forbidden, however, you can contact us to assist you with your transfer to another provider.
Я помню, что ещё тогда вполне однозначно понял это так: «мы отказываем вам в хостинге и всех дополнительных услугах, но нарушать правила ICANN нам ссыкотно, поэтому разделегировать ваши домены мы не решились». Ну, так оно и случилось: никто мои домены не удалил, хотя после такого я, конечно же, перевёл их к другому регистратору как только представилась возможность (а это было нескоро).
Очень удивлён, что они вдруг так осмелели и реально попытались заблокировать домены.
не самый дружелюбный сервис [...] допустим, Scaleway давал аж месяц в долг на поиск нового способа оплаты
Кстати говоря, в том письме они просили не найти другой способ оплаты, а свалить куда подальше по-хорошему:
From now on you will not be able to order new resources. Without a clear change in the foreseeable future, we need to find a way to help you migrate away from Scaleway.
И великодушно дали на это дело срок до 20 апреля. Однако, уже 25 марта мне пришло письмо счастья от каких-то французских коллекторов CFR Recouvrements:
We kindly remind you of your outstanding balance of 2.05 euros owed to your Cloud provider, Scaleway/Elements company. [...] Failure to settle your debt within the next 10 days would oblige us to start legal proceedings to collect this debt without further notice to you.
Не знаю, как вам, а мне это совсем не показалось дружелюбным.
В этом случае несколько теряется двухфакторность. Как-то оно выглядит правильней, когда парольный менеджер и TOTP-аутентификатор обитают на разных устройствах.
Aegis. Опенсорс, умеет абсолютно всё, что требуется от TOTP-приложения (в том числе показывать следующий код). Киллер-фича — экспорт ключей и автоматические шифрованные бэкапы в ФС телефона или на гугл-диск. Но только под Android.
Поэтому смотрю на Иран --- туда авианосная группа приплыла.
Вы так говорите, как будто она туда приплыла ради защиты интересов гражданского общества Ирана, а не американского капитала. И человеколюбия у этой авианосной группы ничуть не больше, не понимаю, почему она вас так радует.
В математике это нормально и идиоматично, поэтому когда адаптируют в код сложные формулы, часто так и оставляют. Проще найти ошибку глазами, когда и на бумаге, и в коде переменные называются одинаково. Проще документировать код, когда можно сослаться на статью, где всё то же самое в тех же самых обозначениях.
По стилю видно, конечно, не всё, но небрежность оформления выдаёт нубов.
Вы видели когда-нибудь, что пишут студенты, не привыкшие к простому текстовому редактору (а часто ещё и к английской раскладке)? Им показываешь на лекциях нормально оформленный код, а в ответ получаешь нагромождение символов без отступов и пробелов вообще — просто не видят ценности тратить усилия на оформление.
и кем "принято"
Во многих популярных языках есть стандартный кодстайл, навскидку: Python, C#, Go, Rust.
Предвыборка данных глубочайше равнодушна, к тому с какой стороны начали читать линию
Предвыборка — это когда вы ещё ни с какой стороны не начали читать линию, а она ужа в кеше. И этому механизму есть дело до направления. Cами по себе кеш-строки слишком короткие, а дорога до оперативной памяти — слишком долгая, чтобы процессор мог позволить себе загружать в кеш только те строки, которые были явно запрошены.
А, теперь понятно, что именно вы имеете в виду под "бэкапом из коробки".
Поверьте, если не обсуждать цену, то с точки зрения администратора SQL Server - приятная и надежная в работе СУБД
Да я даже не спорю. Мне было интересно, что вы имеете в виду под проблемами с бэкапом, а вы, кажется, решили, что я заранее с чем-то не согласен.
Это не из коробки, и это не бекап
Ну, это почти из коробки (apt install zfsutils-linux). Но вообще, я имел в виду, что для PostgreSQL это штатный способ бэкапа, прямо одобренный в документации (с оговоркой "если вы доверяется реализации атомарных снапшотов в файловой системе").
Мне очень нравится этот подход: он определяет границу, после которой с бэкапом базы можно работать как просто с любыми файлами. Это сильно уменьшает количество магии в процедуре, увеличивает понимание происходящего и позволяет действовать привычным инструментарием.
Задача — обеспечить восстановление базы хотя бы на конец каждого дня
Я сам такие большие базы не поднимал, но если рассуждать теоретически, подход с ZFS должен отлично показать себя в таком сценарии: снапшоты создаются быстро, не дублируют старые данные, а переиспользуют общие блоки, поэтому эффективность хранения будет очень хорошей. И можно спокойно удалить любой снапшот, на консистентность оставшихся это никак не повлияет. И после того, как снапшот создан, он уже иммутабелен, можно не торопясь отправить его файлы в холодное хранилище любым удобным способом (в другом комментарии я предлагал для этого restic).
Есть, конечно же, и недстатки, но мне кажется, для многих они не особо критичны:
Снапшотится весь инстанс целиком, не отдельная БД.
Чтобы восстановиться из снапшота, придётся ненадолго остановить постгрес.
А дальше возможны варианты. Например, отправить на другой хост через zfs send, он умеет работать инкрементно (см. также syncoid). Или другой вариант — отправить в облако с помощь rclone или restic (умеет в дедупликацию).
Это работает, если у меня там сидит в офисе всегда в рабочее время главный бухгалтер, которому я делегировал эти полномочия, и дал ему ключ. А в остальных случаях не работает.
Из любопытства спрашиваю: расскажите, пожалуйста, про остальные случаи. Как-то не представляю себе такую организацию дел, когда в компании абы кто абы когда должен иметь возможность отдавать платёжные поручения от лица руководителя, а иначе всё встанет. Всегда есть доверенное лицо.
Там приложение само решает, какому уровню "доверенности" должно соответствовать устройство. Графен проходит базовую проверку, но не усиленную — потому что образ системы подписан не ключом гугла, а своим собственным. А так как механизм проверки завязан на аппаратную аттестацию, обойти его не получится (разработчики GrapheneOS не собираются даже пытаться).
К счастью, далеко не каждое приложение настаивает на усиленной проверке, и все важные лично для меня приложения (включая банковские) вполне нормально работают. Но ситуация может в любой момент измениться — тем более, что прецеденты уже есть:
This is a list of the apps banning GrapheneOS with the Play Integrity API with links to their Play Store pages for leaving feedback:
myGov (Australian government app)
gov.br (Brazilian government app)
Ticketcorner
Authy
Chyrpe Dating
eBay
McDonald's (International app used for many but not all countries not including the US)
Dott
SwissID
TK-App (German health insurance app which uses it for fingerprint login)
IO (Italian government app which uses it for the digital wallet feature)
Вас ещё можно переубедить или это уже неизбежно случится? Я бы не хотел продолжения серии — очень не нравится такой стиль изложения, когда мало информации и много эмоций.
Ситуация обычная. Работа менеджмента в том и состоит, чтобы с такими справляться. Как правило, нет никакой «проблемы старожилов» (кстати, это слово так склоняется, а не как у вас в тексте), а есть другие приоритеты у руководства.
Не нужно ничего модифицировать — в ядре уже имеется механизм
binfmt_misc, позволяющий запускать чужеродные бинарники. Например, я использовал его вместе с qemu для сборки модулей ядра для ARM-одноплатника (очень не хотелось возиться в кросс-компиляцией).Юзкейс «запускать исполнимые файлы Windows через Wine при помощи binfmt_misc» настолько очевиден, что приводится как пример в man binfmt.d и википедии. Это никакая не панацея, а скорее финальный штрих, которой можно сделать для удобства, когда все остальные проблемы с совместимостью уже решены.
Я вижу два возможных сценария, где это могло бы быть полезно:
Можно сразу начать вбивать следующий код, если понимаешь, что текущий уже не успеешь набрать до истечения его срока действия. Не нужно будет стирать уже набранные знаки и начинать всё заново.
Если вдруг попадётся ненормальный сайт, который не следует рекомендации стандарта TOTP принимать не только актуальный код, но и предыдущий и следующий, эта фича может выручить. Кажется, когда-то давно у меня подобное было с Госуслугами — не принимался код и всё тут. Помогло быстро ввести код в самом начале срока его действия.
Я сам не пользуюсь этой опцией, но она есть в Aegis — в другой ветке её упоминали как киллер-фичу неизвестного мне приложения Ente Auth.
Нисколько не хочу защищать Namecheap, но было всё-таки не так. Попросили свалить в течение недели. Формулировка в том письме (от 28 февраля) была такая:
Я помню, что ещё тогда вполне однозначно понял это так: «мы отказываем вам в хостинге и всех дополнительных услугах, но нарушать правила ICANN нам ссыкотно, поэтому разделегировать ваши домены мы не решились». Ну, так оно и случилось: никто мои домены не удалил, хотя после такого я, конечно же, перевёл их к другому регистратору как только представилась возможность (а это было нескоро).
Очень удивлён, что они вдруг так осмелели и реально попытались заблокировать домены.
Кстати говоря, в том письме они просили не найти другой способ оплаты, а свалить куда подальше по-хорошему:
И великодушно дали на это дело срок до 20 апреля. Однако, уже 25 марта мне пришло письмо счастья от каких-то французских коллекторов CFR Recouvrements:
Не знаю, как вам, а мне это совсем не показалось дружелюбным.
Поэтому я искал приложение, умеющее экспортировать ключи и делать шифрованные бэкапы своей базы (см. ниже комментарий про Aegis).
В этом случае несколько теряется двухфакторность. Как-то оно выглядит правильней, когда парольный менеджер и TOTP-аутентификатор обитают на разных устройствах.
Aegis. Опенсорс, умеет абсолютно всё, что требуется от TOTP-приложения (в том числе показывать следующий код). Киллер-фича — экспорт ключей и автоматические шифрованные бэкапы в ФС телефона или на гугл-диск. Но только под Android.
Вы так говорите, как будто она туда приплыла ради защиты интересов гражданского общества Ирана, а не американского капитала. И человеколюбия у этой авианосной группы ничуть не больше, не понимаю, почему она вас так радует.
В математике это нормально и идиоматично, поэтому когда адаптируют в код сложные формулы, часто так и оставляют. Проще найти ошибку глазами, когда и на бумаге, и в коде переменные называются одинаково. Проще документировать код, когда можно сослаться на статью, где всё то же самое в тех же самых обозначениях.
По стилю видно, конечно, не всё, но небрежность оформления выдаёт нубов.
Вы видели когда-нибудь, что пишут студенты, не привыкшие к простому текстовому редактору (а часто ещё и к английской раскладке)? Им показываешь на лекциях нормально оформленный код, а в ответ получаешь нагромождение символов без отступов и пробелов вообще — просто не видят ценности тратить усилия на оформление.
Во многих популярных языках есть стандартный кодстайл, навскидку: Python, C#, Go, Rust.
Предвыборка — это когда вы ещё ни с какой стороны не начали читать линию, а она ужа в кеше. И этому механизму есть дело до направления. Cами по себе кеш-строки слишком короткие, а дорога до оперативной памяти — слишком долгая, чтобы процессор мог позволить себе загружать в кеш только те строки, которые были явно запрошены.
А, теперь понятно, что именно вы имеете в виду под "бэкапом из коробки".
Да я даже не спорю. Мне было интересно, что вы имеете в виду под проблемами с бэкапом, а вы, кажется, решили, что я заранее с чем-то не согласен.
Ну, это почти из коробки (
apt install zfsutils-linux). Но вообще, я имел в виду, что для PostgreSQL это штатный способ бэкапа, прямо одобренный в документации (с оговоркой "если вы доверяется реализации атомарных снапшотов в файловой системе").Мне очень нравится этот подход: он определяет границу, после которой с бэкапом базы можно работать как просто с любыми файлами. Это сильно уменьшает количество магии в процедуре, увеличивает понимание происходящего и позволяет действовать привычным инструментарием.
Я сам такие большие базы не поднимал, но если рассуждать теоретически, подход с ZFS должен отлично показать себя в таком сценарии: снапшоты создаются быстро, не дублируют старые данные, а переиспользуют общие блоки, поэтому эффективность хранения будет очень хорошей. И можно спокойно удалить любой снапшот, на консистентность оставшихся это никак не повлияет. И после того, как снапшот создан, он уже иммутабелен, можно не торопясь отправить его файлы в холодное хранилище любым удобным способом (в другом комментарии я предлагал для этого
restic).Есть, конечно же, и недстатки, но мне кажется, для многих они не особо критичны:
Снапшотится весь инстанс целиком, не отдельная БД.
Чтобы восстановиться из снапшота, придётся ненадолго остановить постгрес.
А дальше возможны варианты. Например, отправить на другой хост через
zfs send, он умеет работать инкрементно (см. также syncoid). Или другой вариант — отправить в облако с помощьrcloneилиrestic(умеет в дедупликацию).Через
zfs snapshot— это из коробки? Если что, вопрос не риторический был, мне искренне интересно, какие там подводные камни.Это ведь шпилька в адрес какой-то из свободных СУБД? Можете для тех, кто не в теме рассказать подробней, в чём проблема с бэкапами в PostgreSQL/MySQL?
А насколько критично в этом случае иметь возможность сделать банковский перевод прям из полей с телефона, а не вечером дома с компьютера?
Из любопытства спрашиваю: расскажите, пожалуйста, про остальные случаи. Как-то не представляю себе такую организацию дел, когда в компании абы кто абы когда должен иметь возможность отдавать платёжные поручения от лица руководителя, а иначе всё встанет. Всегда есть доверенное лицо.
Это совсем не так. Аппаратная аттестация не для того придумывалась, чтобы её можно было "не так уж сложно" обойти.
Там приложение само решает, какому уровню "доверенности" должно соответствовать устройство. Графен проходит базовую проверку, но не усиленную — потому что образ системы подписан не ключом гугла, а своим собственным. А так как механизм проверки завязан на аппаратную аттестацию, обойти его не получится (разработчики GrapheneOS не собираются даже пытаться).
К счастью, далеко не каждое приложение настаивает на усиленной проверке, и все важные лично для меня приложения (включая банковские) вполне нормально работают. Но ситуация может в любой момент измениться — тем более, что прецеденты уже есть: