Блогер делает обзор передачи показывая что половина фактов не актуальна, другая половина откровенное вранье, а суть передачи — отвлечение избирателей от внутренних проблем.
А для этого обязательно копировать оригинальный видеоряд? Мне кажется, достаточно составить список фактов в виде (скажем) слайдов и прокомментировать их.
К тому же, включение оригинального видеоряда — это избыточное время, нет смысла вставлять несколько минут видео где можно обойтись парой фраз о его содержании.
Блогер «Б» берет это видео, монтирует его и добавляет свой видеоряд со своими комментариями.
Что мешает блогеру «Б» оставить только свой видеоряд и свои комментарии, ссылаясь на оригинальную новость? Если уж подписчикам действительно интересно его мнение, то они всё равно его выслушают.
… как было бы классно, если бы приложение работало в идеальных условиях, где кроме браузера ничего не запущено, а подкачки нет
С точки зрения приложения — ему не нужно знать какие ещё есть приложения, ему нужно знать только какие ресурсы ему выделены, а не пытаться взять всё что есть. Если у меня (условно) 8G памяти, я хочу иметь возможность сказать приложению — «у тебя есть 4G, крутись как хочешь». Почему только 4G, это не его дело — и вот тут как раз встроенное управление памятью/гибернацией важно (потому что ОС точно этого не сделает — в рамках установленных ограничений на процесс).
Подобный механизм (ограничение памяти приложения или их группы) встроен в Linux (и похожие системы) изначально (ulimit/cgroup), в Windows есть некий аналог (Job Objects) — и это правильных подход. В реальной же жизни браузер зачем-то ориентируется на свободную память всей системы (как раз «думая» что он один во всей системе) — и это неправильно.
ОС как раз точно знает, какие страницы использовались в последнее время.
Но она не знает когда они понадобятся в следующий раз, и как быстро.
Вообще управление подкачкой в любой ОС очень сферическое в вакууме — несмотря на то что «в среднем» оно делает полезное дело, оно не учитывает (и не может) ряд частных случаев, браузер и его вкладки является одним из них.
И в чем отличие от гибернации? Что будет держать вашу любимую вкладку в памяти при гибернации?
Вероятно, то, что приложению можно явно сказать об этом? Как это реализовано в The Great Suspender, например (хотя и не идеально).
Ещё раз повторюсь — любое приложение лучше чем ОС знает свои потребности (и потребности пользователя), соответственно, лучше справится с управлением выгрузкой. Но посколько ОС средств такого управления не предоставляет (и не гарантирует), то остается только делать всё внутри. Вот если ОС даст возможность приложению сказать «выгрузить эту область памяти» и «загрузить эту и сказать когда готово» — можно будет полноценно это использовать.
И снова — гибернация в приложении позволяет сохранить состояние независимо от ОС, и продолжить в нужный момент (после рестарта или обновления) — Session Buddy является моделью этого (хотя и не посредством гибернации, к сожалению).
Я рад, что вам не приходилось писать приложения больше 100к строк кода.
Одному — не приходилось, в команде — было дело. И можете не верить, но каждый из девелоперов знал (пусть и не в деталях) о взаимодействии модулей, их целях и задачах. При наличии хорошо продуманной архитектуры и наличии соглашений это не так сложно (впрочем, при их отсутствии у вас будет масса других проблем).
Я уже говорил, что в виндусе дисковые операции активно вытесняют память приложений в своп.
До этого вы говорили про «нехватку памяти». Так или иначе, это ещё одна причина по которой своп стоит выключить (при наличии достаточного количества RAM) — что бы ОС не делала то что она «считает» нужным, хотя это не всегда так.
Им уже дан сверху этот механизм, который как-то работает и им нужно в этих условиях что-то сделать полезное.
Им не дан этот механизм — я уже сказал выше почему — ни одна из популярных десктопных ОС не гарантирует наличия файла подкачки, и не дает средств контроля над ним. Расчитывать на то что может быть включено, а может быть нет — это как минимум глупо. Требовать включения — ещё глупее, всё равно что требовать наличия SSD вместо абстрактного диска (который может быть в RAM или сетевым и в 100500 раз лучше/быстрее).
Ваш прекрасный выдуманный мир, где вы собственноручно решаете какой процесс нужно выгрузить, я рассматривать не хочу.
Этот «выдуманный мир» реализован (пусть и не в полной мере) в Vivaldi, например, и также доступен для всех кто использует The Great Suspender (который, кстати, использует встроенные механизмы Chrome) — а это говорит о том что фича нужная. Есть и другие разработки в этом направлении, что тоже говорит о востребованности «выдуманного» мира.
ОС как раз знает по факту, какие данные являются горячими.
ОС как раз не знает — предполагает. В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные, я хочу их в любой произвольный момент времени в памяти, а не в свопе (даже если я её неделю не трогал) — но ОС может подумать что их можно выгрузить если они длительно не использовались (что она и делает).
то что ваш код не использует какие-то данные, не значит что их не использует какой-то другой код
Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.
А показатель того, что память нужно выгружать — нехватка памяти.
Да ну? Что ж тогда при её использовании максимум на 50% в своп что-то валится? Где ж эта «нехватка»? Причем и в линухе и в вынь, что примечательно. Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу. Это моя система, мне лучше знать когда и кому что отдавать. В конце концов, я специально поставил в два раза больше памяти чем может потребоваться чтобы обходится без подкачки.
Тут все просто — либо мы хотим многозадачности и тогда нужна подкачка и выгружать можно всё что угодно.
Я не совсем понимаю — причём тут вообще «многозадачность»? Без подкачки всё отлично работает (если памяти достаточно) — чем её отсутствие мешает «многозадачности»? Количество процессов или потоков не зависит от наличия или отсутствия подкачки, их одновременная работа и взаимодействие тоже.
А гибернация знает заранее?
Да. Потому что я могу поставить на вкладке метку «не трогать» — и её никто не тронет. Или приложение может реализовать свой алгоритм (типа «гибернировать только если месяц не трогали»). Существует масса способов дать хинт приложению — как алгоритмический, так и явный (от пользователя), а использование подкачки — процесс абсолютно независимый от желания и намерений пользователя и/или приложения, его невозможно контролировать (даже на линухе — swappiness мало помогает).
Стандартный механизм != гарантированный механизм. Никакая ОС (кроме, возможно, узко специализированных) не гарантирует ни наличия подкачки, ни её размеров. Пока требование наличия подкачки (вообще или определенных размеров) отсутствует для приложений, нужно расчитывать что её нет совсем. Впрочем, приложение с требованиями наличия файла подкачки, скорее всего, отправится в корзину большинством адекватных пользователей.
Приложение не имеет контроля над алгоритмами подкачки, а ОС не имеет понятия о том что является горячими или холодными данными для приложения, простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).
Приложение может сказать «не выгружать область памяти X» посредством mlock()/VirtualLock() (хотя и в ограниченных пределах), но не может сказать «выгрузить область X немедленно» или «вернуть область X в память и сообщить когда готово» (неявный возврат при обращении == лаг для приложения). Хуже того, выгруженные данные вне контроля приложения, они не сохраняются при завершении приложения, и приложение понятия не имеет, выгружены они или нет на самом деле. Если некоторые данные (вкладка) мне нужны раз в день, но мгновенно — то подкачка только всё испортит, она не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.
Насчёт «истинной» многозадачности (не знаю что уж вы имеете в виду под «истинной») — то многозадачность существовала задолго до механизмов подкачки и прекрасно обходится без них и сейчас. Есть масса задач где подкачка вообще явно запрещена (именно в связи с тем что она непредсказуема и неэффективна).
Насчёт своего менеджера памяти — о да, ну конечно не нужно — именно поэтому существует с десяток библиотек а-ля malloc() и сборщиков мусора, и почти каждый крупный проект делает свой. И именно поэтому существуют сотни вариантов сериализации данных и десятки форматов их хранения (не для баз данных), не так ли?
Насчёт половины экрана — во-первых, экран, в отличие от файла подкачки, вещь монолитная и неделимая, если уж он есть, вы вправе расчитывать известное вам разрешение, то он весь ваш. Но тут появляется во-вторых — кто-то додумался до экранов круглой и других форм, и (внезапно) вы даже на это не можете расчитывать (уже почти картонка). И в-третьих, монобровь на некоторых мобильных передаёт вам пламенный привет — это конечно не пол-экрана, но всё же досадное недоразумение в весьма популярном для всяких контролов месте, и нравится вам это или нет, но либо вы это учитываете в своём приложении либо теряете долю пользователей с таким железом.
Так что да — уж извините, но я буду «кричать» — девелоперы должны учитывать реальные системы и реальные потребности пользователей, если они делают продукт не для себя.
В конце концов, если бы файл подкачки был настолько универсальным и единственно правильным («истинным», наверное?) методом — то вопрос гибернации вкладок вообще бы сейчас не обсуждался, и не было бы массы причиндал для этого. Но реальность такова, что он никак не может заменить «нативную» гибернацию, и никакие апологеты механизма подкачки этого не изменят.
Ну разумеется. Как типично для современных разработчиков — вместо оптимизации софта сказать нечто в духе «добавьте памяти» или «добавьте своп». Им-то, конечно, лучше знать, как пользователю пользовать.
Преимущество в том что не у всех есть файлы подкачки. Например, на моём компе 32GB памяти, и в связи с тем что она редко используется хотя бы наполовину, подкачки нет, но я предпочел бы чтобы Chrome (или другой браузер) не разрастался до нескольких гигабайт — а такое случается если вкладок много, и некоторые текут в фоне (roundcube/proxmox — яркие примеры).
К сожалению, девелоперы браузеров почему-то считают что гибернацию нужно начинать только когда свободной памяти мало — а это часто неправильно, ибо когда её мало вообще — то обычно поздно пить боржоми (браузер не единственный процесс в системе).
Ещё одно преимущество гибернации в приложении — это как раз независимость от файла подкачки — его можно закрыть (с гибернацией), потом открыть и продолжить с точки закрытия.
Честно говоря, в вашем конкретном случае, раз уж неважно как завершится child, вам вообще не нужно обрабатывать сигналы. Просто делаете (в начале main()):
signal(SIGCHLD, SIG_IGN);
и забываете про зомби как страшный сон — их просто не будет. Для этого простейшего случая использование signal() вместо sigaction() вполне адекватно.
wait() нужно только если вам важен код завершения процесса или если нужно дождаться завершения оного.
Это зависит от того, разрешен ли безусловный overcommit (значение 1). Если да, то ядро не будет проверять наличие памяти до того как она реально используется (т.е. в неё реально что-то запишут). По умолчанию значение параметра 0 (использовать эвристику), и в этом случае ядро будет (скорее всего) проверять память с учётом свопа.
Просто из вредности я проверил это на 4.15 (поставив vm.overcommit_memory=1), без проблем всё работает (как и ожидалось). Ядро 4.15 (Ubuntu 18.04), реальной памяти 2G, свопа нет, процесс запрашивает 1G памяти через calloc() и потом делает fork() 16 раз — без проблем.
Если посмотреть на процессы, то видно 17 процессов и каждый имеет резидентных чуть более 1G — но реально этот 1G является shared memory. Если же дети начнут писать в эту память — вот тогда начнутся проблемы.
Вся информация о завершении процесса влезает в тип данных int.
На самом деле это не совсем так — можно получить несколько больше информации о завершении процесса, если использовать waitid() и потом изучить данные из siginfo_t. Это тоже далеко не всё (есть ещё taskstats), хотя в большинстве случаев это мало кому нужно.
Не понимаю, как по-вашему команды системы СКУД могут быть не sensitive. Если за этими дверьми нет ничего sensitive, то зачем систему покупали?
Замки ставят даже на комнатки для уборщиков и кухни, где нет абсолютно ничего sensitive.
Я подозреваю что там действительно нет ничего настолько важного чтобы заморачиваться драконовскими методами защиты — то есть при установке риск был оценен как «низкий», со всеми вытекающими. Но разумеется, когда обнаружилась «дыра», это нельзя было просто так оставлять.
Самая банальная причина, кстати — это просто учёт кто куда и когда ходит, для статистики.
Устроится на работу электриком в компанию, обслуживающую офисы Google — это, как мне кажется, уж слишком для social engineering, это уже скорей некий вариант атаки инсайдера.
Зачем устраиваться? Заплатить уже действующему работнику (или шантажировать его), и всех делов. Для особо продвинутых — подменить его кем-то своим в нужный момент (да, это бывает и в реальной жизни, а не только в фильмах). Впрочем, это всё будет иметь смысл только если там (за дверями) реально что-то исключительно важное, иначе игра не стоит свеч.
Всё что вы пишите в принципе очень правильно, но есть простое объяснение — доверие. Если вы покупаете сейф от известной фирмы, вы не будете лично проверять его надежность, так как знаете что сейфы этой фирмы надежны. Через время может оказаться что это не так, и вы примете меры — а пока этого не случилось — вы вряд-ли будете прятать его в бункере и нанимать «медвежатников» для его проверки.
Когда вы поднимаете у себя SSH сервер, вы вряд-ли расчитываете что у него где-то дыра — и также вряд-ли проверяете его код (и код всех используемых им зависимостей), плюс все используемые алгоритмы шифрования и аутентификации. Нет, конечно, можно ещё для «надежности» завернуть его в VPN, но — а вдруг у этого VPN тоже дыра (особенно если это закрытое решение)? Завернете его в другой VPN или построите свои каналы связи, охраняемые собаками Баскервилей по всей протяженности?
До какого уровня вы готовы (и способны) всё проверять и прятать?
Видимо, тот факт что на глаз трудно определять какой борт какой, по крайней мере в аэропортах с большим траффиком, да и строить в уме картинку их взаимного расположения, относительных скоростей, эшелонов — и всё это наблюдая в бинокль? Я уже молчу про случай когда видимость менее 1000 метров…
Было бы интересно узнать, в чём несовместимость безопасности и номера телефона при end-to-end шифровании сообщений, особенно для большинства коммуникаций, где номер телефона секретом не является (клиент-фирма, фирма-фирма и большинство клиент-клиент для людей, не нарушающих закон и далеких от политики).
А в чём проблема? Налоги и отчетности строго формализованы, лазейки известны, робот с этим справится даже лучше человека. Бот-юрист уже есть давно, дела выигрывает, почему бы не появиться боту-бухгалтеру, который отчётности составляет в пользу фирмы, манипулируя данными о способах оптимизации налогов? Отчасти, нужно сказать, это уже реализовано — в Германии, к примеру, есть программулины для предпринимателей, в которые просто тупо забиваешь всё что есть, отвечаешь на наводящие вопросы, а они составляют (и сами подают) идеальные отчёты, списывая всё что можно. А самое главное — они не ошибаются, ничего не пропускают и ничего не забывают, только кнопку дави.
А для этого обязательно копировать оригинальный видеоряд? Мне кажется, достаточно составить список фактов в виде (скажем) слайдов и прокомментировать их.
К тому же, включение оригинального видеоряда — это избыточное время, нет смысла вставлять несколько минут видео где можно обойтись парой фраз о его содержании.
Что мешает блогеру «Б» оставить только свой видеоряд и свои комментарии, ссылаясь на оригинальную новость? Если уж подписчикам действительно интересно его мнение, то они всё равно его выслушают.
Логика просто супер. Так и хочется продолжить — «не стоит обвинять насильника в насилии — не он его придумал».
С точки зрения приложения — ему не нужно знать какие ещё есть приложения, ему нужно знать только какие ресурсы ему выделены, а не пытаться взять всё что есть. Если у меня (условно) 8G памяти, я хочу иметь возможность сказать приложению — «у тебя есть 4G, крутись как хочешь». Почему только 4G, это не его дело — и вот тут как раз встроенное управление памятью/гибернацией важно (потому что ОС точно этого не сделает — в рамках установленных ограничений на процесс).
Подобный механизм (ограничение памяти приложения или их группы) встроен в Linux (и похожие системы) изначально (ulimit/cgroup), в Windows есть некий аналог (Job Objects) — и это правильных подход. В реальной же жизни браузер зачем-то ориентируется на свободную память всей системы (как раз «думая» что он один во всей системе) — и это неправильно.
Но она не знает когда они понадобятся в следующий раз, и как быстро.
Вообще управление подкачкой в любой ОС очень сферическое в вакууме — несмотря на то что «в среднем» оно делает полезное дело, оно не учитывает (и не может) ряд частных случаев, браузер и его вкладки является одним из них.
Вероятно, то, что приложению можно явно сказать об этом? Как это реализовано в The Great Suspender, например (хотя и не идеально).
Ещё раз повторюсь — любое приложение лучше чем ОС знает свои потребности (и потребности пользователя), соответственно, лучше справится с управлением выгрузкой. Но посколько ОС средств такого управления не предоставляет (и не гарантирует), то остается только делать всё внутри. Вот если ОС даст возможность приложению сказать «выгрузить эту область памяти» и «загрузить эту и сказать когда готово» — можно будет полноценно это использовать.
И снова — гибернация в приложении позволяет сохранить состояние независимо от ОС, и продолжить в нужный момент (после рестарта или обновления) — Session Buddy является моделью этого (хотя и не посредством гибернации, к сожалению).
Одному — не приходилось, в команде — было дело. И можете не верить, но каждый из девелоперов знал (пусть и не в деталях) о взаимодействии модулей, их целях и задачах. При наличии хорошо продуманной архитектуры и наличии соглашений это не так сложно (впрочем, при их отсутствии у вас будет масса других проблем).
До этого вы говорили про «нехватку памяти». Так или иначе, это ещё одна причина по которой своп стоит выключить (при наличии достаточного количества RAM) — что бы ОС не делала то что она «считает» нужным, хотя это не всегда так.
Им не дан этот механизм — я уже сказал выше почему — ни одна из популярных десктопных ОС не гарантирует наличия файла подкачки, и не дает средств контроля над ним. Расчитывать на то что может быть включено, а может быть нет — это как минимум глупо. Требовать включения — ещё глупее, всё равно что требовать наличия SSD вместо абстрактного диска (который может быть в RAM или сетевым и в 100500 раз лучше/быстрее).
Этот «выдуманный мир» реализован (пусть и не в полной мере) в Vivaldi, например, и также доступен для всех кто использует The Great Suspender (который, кстати, использует встроенные механизмы Chrome) — а это говорит о том что фича нужная. Есть и другие разработки в этом направлении, что тоже говорит о востребованности «выдуманного» мира.
ОС как раз не знает — предполагает. В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные, я хочу их в любой произвольный момент времени в памяти, а не в свопе (даже если я её неделю не трогал) — но ОС может подумать что их можно выгрузить если они длительно не использовались (что она и делает).
Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.
Да ну? Что ж тогда при её использовании максимум на 50% в своп что-то валится? Где ж эта «нехватка»? Причем и в линухе и в вынь, что примечательно. Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу. Это моя система, мне лучше знать когда и кому что отдавать. В конце концов, я специально поставил в два раза больше памяти чем может потребоваться чтобы обходится без подкачки.
Я не совсем понимаю — причём тут вообще «многозадачность»? Без подкачки всё отлично работает (если памяти достаточно) — чем её отсутствие мешает «многозадачности»? Количество процессов или потоков не зависит от наличия или отсутствия подкачки, их одновременная работа и взаимодействие тоже.
Да. Потому что я могу поставить на вкладке метку «не трогать» — и её никто не тронет. Или приложение может реализовать свой алгоритм (типа «гибернировать только если месяц не трогали»). Существует масса способов дать хинт приложению — как алгоритмический, так и явный (от пользователя), а использование подкачки — процесс абсолютно независимый от желания и намерений пользователя и/или приложения, его невозможно контролировать (даже на линухе — swappiness мало помогает).
Приложение не имеет контроля над алгоритмами подкачки, а ОС не имеет понятия о том что является горячими или холодными данными для приложения, простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).
Приложение может сказать «не выгружать область памяти X» посредством mlock()/VirtualLock() (хотя и в ограниченных пределах), но не может сказать «выгрузить область X немедленно» или «вернуть область X в память и сообщить когда готово» (неявный возврат при обращении == лаг для приложения). Хуже того, выгруженные данные вне контроля приложения, они не сохраняются при завершении приложения, и приложение понятия не имеет, выгружены они или нет на самом деле. Если некоторые данные (вкладка) мне нужны раз в день, но мгновенно — то подкачка только всё испортит, она не знает что если нечто не использовалось аж 23 часа может вдруг потребоваться мгновенно и заранее подкачать это к нужному моменту.
Насчёт «истинной» многозадачности (не знаю что уж вы имеете в виду под «истинной») — то многозадачность существовала задолго до механизмов подкачки и прекрасно обходится без них и сейчас. Есть масса задач где подкачка вообще явно запрещена (именно в связи с тем что она непредсказуема и неэффективна).
Насчёт своего менеджера памяти — о да, ну конечно не нужно — именно поэтому существует с десяток библиотек а-ля malloc() и сборщиков мусора, и почти каждый крупный проект делает свой. И именно поэтому существуют сотни вариантов сериализации данных и десятки форматов их хранения (не для баз данных), не так ли?
Насчёт половины экрана — во-первых, экран, в отличие от файла подкачки, вещь монолитная и неделимая, если уж он есть, вы вправе расчитывать известное вам разрешение, то он весь ваш. Но тут появляется во-вторых — кто-то додумался до экранов круглой и других форм, и (внезапно) вы даже на это не можете расчитывать (уже почти картонка). И в-третьих, монобровь на некоторых мобильных передаёт вам пламенный привет — это конечно не пол-экрана, но всё же досадное недоразумение в весьма популярном для всяких контролов месте, и нравится вам это или нет, но либо вы это учитываете в своём приложении либо теряете долю пользователей с таким железом.
Так что да — уж извините, но я буду «кричать» — девелоперы должны учитывать реальные системы и реальные потребности пользователей, если они делают продукт не для себя.
В конце концов, если бы файл подкачки был настолько универсальным и единственно правильным («истинным», наверное?) методом — то вопрос гибернации вкладок вообще бы сейчас не обсуждался, и не было бы массы причиндал для этого. Но реальность такова, что он никак не может заменить «нативную» гибернацию, и никакие апологеты механизма подкачки этого не изменят.
К сожалению, девелоперы браузеров почему-то считают что гибернацию нужно начинать только когда свободной памяти мало — а это часто неправильно, ибо когда её мало вообще — то обычно поздно пить боржоми (браузер не единственный процесс в системе).
Ещё одно преимущество гибернации в приложении — это как раз независимость от файла подкачки — его можно закрыть (с гибернацией), потом открыть и продолжить с точки закрытия.
и забываете про зомби как страшный сон — их просто не будет. Для этого простейшего случая использование signal() вместо sigaction() вполне адекватно.
wait() нужно только если вам важен код завершения процесса или если нужно дождаться завершения оного.
Просто из вредности я проверил это на 4.15 (поставив vm.overcommit_memory=1), без проблем всё работает (как и ожидалось). Ядро 4.15 (Ubuntu 18.04), реальной памяти 2G, свопа нет, процесс запрашивает 1G памяти через calloc() и потом делает fork() 16 раз — без проблем.
Если посмотреть на процессы, то видно 17 процессов и каждый имеет резидентных чуть более 1G — но реально этот 1G является shared memory. Если же дети начнут писать в эту память — вот тогда начнутся проблемы.
На самом деле это не совсем так — можно получить несколько больше информации о завершении процесса, если использовать waitid() и потом изучить данные из siginfo_t. Это тоже далеко не всё (есть ещё taskstats), хотя в большинстве случаев это мало кому нужно.
Замки ставят даже на комнатки для уборщиков и кухни, где нет абсолютно ничего sensitive.
Я подозреваю что там действительно нет ничего настолько важного чтобы заморачиваться драконовскими методами защиты — то есть при установке риск был оценен как «низкий», со всеми вытекающими. Но разумеется, когда обнаружилась «дыра», это нельзя было просто так оставлять.
Самая банальная причина, кстати — это просто учёт кто куда и когда ходит, для статистики.
Зачем устраиваться? Заплатить уже действующему работнику (или шантажировать его), и всех делов. Для особо продвинутых — подменить его кем-то своим в нужный момент (да, это бывает и в реальной жизни, а не только в фильмах). Впрочем, это всё будет иметь смысл только если там (за дверями) реально что-то исключительно важное, иначе игра не стоит свеч.
Когда вы поднимаете у себя SSH сервер, вы вряд-ли расчитываете что у него где-то дыра — и также вряд-ли проверяете его код (и код всех используемых им зависимостей), плюс все используемые алгоритмы шифрования и аутентификации. Нет, конечно, можно ещё для «надежности» завернуть его в VPN, но — а вдруг у этого VPN тоже дыра (особенно если это закрытое решение)? Завернете его в другой VPN или построите свои каналы связи, охраняемые собаками Баскервилей по всей протяженности?
До какого уровня вы готовы (и способны) всё проверять и прятать?
А те кто за крон берет деньги вообще должны читать исходники ядра побитно вслух.