Вообще это странно что так долго выкатывают пустой рабочий проект. Если в компании используются динамические review/feature/dev/stand/non-production like (как кто привых называть) окружения (не могу поверить что в проектах такого уровня сложности можно жить без них в 2024), то установив "гитлаб", подняв новые ранеры и запушив с машин разработчиков, можно почти без изменений выкатывать хоть сколько то рабочую версию проекта. А не просто лендинг. Представил гипотетическую ситуацию. А что если уровень информационной бИзопасности в компании был настолько высок, что разработчикам нельзя было работать удаленно и/или работать без обязательного подключения компуктора разработчика к домену и/или без установки какой-нибудь резидентной тулзы/системы обеспечивающей бИзопасность (вместе с бИзопасным RCE разумеется) рабочего места (т.е. следящей чтобы разработчик не отправил код "по почте", делающей скриншеты факта открытия небИзопасных сайтов, считающей мышковозюки, и т.п. безумно важные в бИзопасности вещи). Тогда если скажем разработчиков бекенда было человек 10, до достаточно велик шанс что все они после работы не выключили свои ПК (даже не обязательно чтобы это произошло сразу, можно было сначала собрать список ПК разработчиков, а потом дождаться случая когда все ПК будут онлайн ночью). Зачем вообще разработчику выключать ПК? Действительно - незачем. И вот тогда в час Х, когда сошлись все звезды, все хосты заботливо обмазаные бИзопасным RCE начали выполнять не совсем безопасные, но совершенно валидные инструкции из центра бИзопасности. Можно еще предположить что для соевой бИзопасной бИзопасности разработчикам приходилось работать с кодом в "терминальной сессии". "Ишь чего придумали? Неудобно вам... А нам будет удобно, когда код утечет? Знаем мы вас. У нас тут бИзопасность, а не хухры мухры." Навеяно обсуждением на работе: что хватит уже для бИзопасности городить эту абсолютную централизацию, когда все в виндовом домене и все авторизуется через LDAP. А в результате есть куча мест для утечки учетных данных и последующей компрометации всего.
Эта идея (об обмене информацией) не нова. В России её активно развивает автрофизик ДФМН А.Д. Панов, известный тем что является руководителем SETI в России и тем что занимается популяризацией SETI. Рекомендую для ознакомления, если еще не знакомы. У него много интересных мыслей: о "культурном поле", пределах развития цивилизаций, эволюции и панспермии.
А почему "отсутствие локального окружения" так безапеляционно записывается в безусловные плюсы? Помоему это неочевидно. Наличие локального окружения разработки может напорядки (буквально) сократить (как минимум для интерпритируемых языков) RTT между: написал код - увидел результат. Например в нашем случае имеется много проектов на php, результат внесения изменений в которые можно увидеть "нажав f5" на localhost'е. В противном же случае разработчику пришлось бы ждать отработки десятков разных сущностей под капотом ci pipeline'а (банально подготовить репо, собрать образы, прогнать линтеры, запустить развертывание review окружения, прогнать jobs, миграции и init контейнеры). Получить RTT меньше минуты с удаленным окружением на (нашей) практике невозможно. А эта скорость: код -> результат, это именно то для чего devops организовался, это его основное предназначение. И она напрямую конвертируется в скорость поставки фитч на прод и комфорт работы разработчика (которому не нужно больше держать в памяти контекст предыдущего запуска CI и сопоставлять его с изменениями, которые он уже успел написать вперед пока pipeline pending).
Вы забыли важный параграф про получение энергии посредством акреции вещества на черную дыру. В отличии от ТЯ синтеза с его приблизительно 1% mc^2 энерговыходом, акреция вещества на черную дыру дает в предельном случае приблизительно 42% mc^2. С учетом огромной разницы в энергоэффективности и доступности и черных дыр, и остатков звезд, можно ожидать так же значительного продления жизни на данном источнике энергии. Не исключено что такое существование продлится даже не в 42 раза, а еще дольше. Ведь собирать энергию со столь огромной энергоустановки как звезда + панели вокруг неё - это чрезвычайно неэффективное занятие. Слишком мала излучаемая плотность энергии, требуются огромные площади панелей для поглащения этой энергии, отсюда недостатки в КПД и стоимости (=энергоемкости) обслуживания. А вот микроскопическая черная дыра могла бы быть упакована в компактную высокоэффективную энергоустановку.
С памятью все просто... Ну нет, с памятью все еще хуже. :) Во-первых предложеное решение не сработает. Лимиты по памяти должны быть безальтернативно установлены. Иначе это грозит выселением всех подов с ноды или даже зависанием последней. Во-вторых потребности в CPU гораздо проще определяются - смотришь график потребления CPU и выставляешь, и если нагрузка не меняется в 100 раз - у тебя все хорошо. С памятью так вообще не работает и сильно зависит от типа приложения. Одним ставишь лимит на 30% больше максимального RSS - и они работают как ни в чем ни бывало, например nginx. Другим ставить на 2000% больше максимального RSS в районе WSS - они стабильно и воспроизводимо падают, например postgres. Как формализовать установку лимитов по памяти, да так чтобы не тренироваться узнаванием "когда оно падает", до сих пор не знаю. И еще кстати метрики CPU собираются как prometheus counter, а memory как gauge. А это значит что пропустить пик потребления CPU, который бы уперся в лимиты - невозможно, а по памяти - запросто (просто не попали и интервал "скребления", приходите "поскребсти" в следующих раз)
На практике (глобальных сетей с потерями) такой кейс невозможен.
Если в сети существуют потери и заметный jitter (хотябы иногда), то почувствовав их на внешнем (VPN транспорт) tcp сеансе, tcp/ip стек машины считает, что в канале перегрузка и начинает уменьшать окно tcp (количество неподтвержденных / передаваемых_в_сей_момент фреймов). Это разумеется аффектит скорость внутрених сеансов. Но само по себе это не так страшно, если забыть о том, что протокол управления окном работает и для них тоже.
И так, последние мало того что они прямым образом «собрали» потери и джиттер от внешнего tcp сеанса — замедлились то тем же правилам. Так для них полоса пропускания канала (внешняя tcp сессия в которой они живут) стала уже, и они вынуждены вставать в очереди, увеличивая время rtt (время двойного прохода, посылки-подтверждения) в том числе на dst хостах для внутрених сеансов. Никто не ожидал, но вот опять: срабатывает протокол управления окном, скорость внутренних сеансов замедляется еще сильнее. И похоже и это не самое плохое.
А вот тут я уже немного вангую. Вероятно возможно какое-то стечение обстоятельств (используемых полос пропускания, имеющихся потерь и джитера), когда доступная полоса для внутрених сессий находится в какомто хрупком равновесии с возможностями внешней сессии, и все это работает относительно нормально. Но потом приходит возмущение, и все идет в полный разнос. С падением полос пропускания в ноль, задержек до десятков секунд. Это я последнее время наблюдаю используя tcp vpn до aws. Пинг по 30 секунд, зато нет потерь. Класс!
А что в случае внешнего udp/ip? Да как сказал «великий классик»: «ну потеря, так потеря», работаем дальше.
Пользователь пойдет на страничку с certificate transparency логом и не обнаружит там этого сертификата.
После этого нелегальный сертификат выкладывается в публичный доступ, рядом ложится ссылка выше - кто угодно может ознакомиться с пруфами инцидента.
Из всего этого будет следовать - закрытый ключ скомпрометирован. Доверия этому УЦ больше нет. Все (кого интересует безопасность) массово поудаляют этот CA. А кого не интересует - для того такой вопрос (Russian CA) просто не стоит. Большинство людей вообще спокойно пользуются ОС Шindoшs и смартфонами, которые в открытую сообщают о сливе информации впользу Васянов не дающих никаких гарантий и находящихся в авшорных юрисдикциях. Чего уж говорить про установку какого-то файлика в браузер, это вообще ерунда какая-то. :)
Это еще что. Они недавно забанили Happy - в прошлом чемпиона мира по Warcraft3 и самого сильного игрока на текущий момент (например последний крупнейший международный турнир с участием сильнейших игроков он выигрыл с разгромным счетом 13:0, не отдав ни одной карты)
2025: Посредством СС, поисковиков, смартфонов, IoT… для 99.73% населения достигнута «маркетинговая полнота». (новый термин описывающий предельный уровень маркетинговой эксплуатации объектов при данном технологическом укладе.) Этап монетизации информации сети закончен. Рост сетевых компаний прекращается.
2033: Релиз проекта консорциума сетевых компаний, корпорации «Прогресса». В теле человека: тысячи микроскопических датчиков посылающих параметры организма в «центр», кибернетический орган по команде синтезирует ферменты, ГМО бактерии и вирусы точечно, без побочных эффектов решающие проблемы. Практическое бессмертие. По условиям контракта пользователь разрешает использование информации в не медицинских целях.
2039: Дифференциация уровня жизни измененных и обычных людей. Омоложение, не болеют, больший интеллект, творчески активнее, живут вечно. Законодательное ограничение рождаемости. Деградация инфраструктуры обычных людей: больницы, школы, ВУЗы… Социальные проблемы: трудности с трудоустройством, большая страховка, налоги… Маргинализация образа жизни обычных людей. Протесты не замечены, «они тут ненадолго».
2041: Прогресс в нейронных сетях, построение модели личности человека и способов её модификации.
2044: Первое дистанционное уничтожение террориста.
2049: Снова достигнута «маркетинговая полнота», монетизация любой информации о человеке закончилась. Не состоялась экстренная конференция по неправомерному применению системы для управления людьми, модифицированный автор разбился на древнем Харлее.
2050: Люди единогласно, самостоятельно приняли решение объединиться в государство «Прогресса».
2117: Исчезновение последнего обычного человека. Принудительная модификация, контроль за технологиями, фактически остановка прогресса. Всеобщая солидарность «против ИИ».
технологии защиты памяти виртуальных машин гипервизора
Это неплохо выглядит, когда оно написано на рекламном плакате.
А на деле, скорее всего, нас опять хотят «защитить» от свободы в использовании ПО.
Столлман приди — порядок наведи!
С добрым утром, уже пол года как не имеет отношения к Open source.
Вообще это странно что так долго выкатывают пустой рабочий проект. Если в компании используются динамические review/feature/dev/stand/non-production like (как кто привых называть) окружения (не могу поверить что в проектах такого уровня сложности можно жить без них в 2024), то установив "гитлаб", подняв новые ранеры и запушив с машин разработчиков, можно почти без изменений выкатывать хоть сколько то рабочую версию проекта. А не просто лендинг.
Представил гипотетическую ситуацию. А что если уровень информационной бИзопасности в компании был настолько высок, что разработчикам нельзя было работать удаленно и/или работать без обязательного подключения компуктора разработчика к домену и/или без установки какой-нибудь резидентной тулзы/системы обеспечивающей бИзопасность (вместе с бИзопасным RCE разумеется) рабочего места (т.е. следящей чтобы разработчик не отправил код "по почте", делающей скриншеты факта открытия небИзопасных сайтов, считающей мышковозюки, и т.п. безумно важные в бИзопасности вещи). Тогда если скажем разработчиков бекенда было человек 10, до достаточно велик шанс что все они после работы не выключили свои ПК (даже не обязательно чтобы это произошло сразу, можно было сначала собрать список ПК разработчиков, а потом дождаться случая когда все ПК будут онлайн ночью). Зачем вообще разработчику выключать ПК? Действительно - незачем. И вот тогда в час Х, когда сошлись все звезды, все хосты заботливо обмазаные бИзопасным RCE начали выполнять не совсем безопасные, но совершенно валидные инструкции из центра бИзопасности.
Можно еще предположить что для
соевойбИзопасной бИзопасности разработчикам приходилось работать с кодом в "терминальной сессии". "Ишь чего придумали? Неудобно вам... А нам будет удобно, когда код утечет? Знаем мы вас. У нас тут бИзопасность, а не хухры мухры."Навеяно обсуждением на работе: что хватит уже для бИзопасности городить эту абсолютную централизацию, когда все в виндовом домене и все авторизуется через LDAP. А в результате есть куча мест для утечки учетных данных и последующей компрометации всего.
Эта идея (об обмене информацией) не нова. В России её активно развивает автрофизик ДФМН А.Д. Панов, известный тем что является руководителем SETI в России и тем что занимается популяризацией SETI. Рекомендую для ознакомления, если еще не знакомы. У него много интересных мыслей: о "культурном поле", пределах развития цивилизаций, эволюции и панспермии.
А почему "отсутствие локального окружения" так безапеляционно записывается в безусловные плюсы? Помоему это неочевидно.
Наличие локального окружения разработки может напорядки (буквально) сократить (как минимум для интерпритируемых языков) RTT между: написал код - увидел результат. Например в нашем случае имеется много проектов на php, результат внесения изменений в которые можно увидеть "нажав f5" на localhost'е. В противном же случае разработчику пришлось бы ждать отработки десятков разных сущностей под капотом ci pipeline'а (банально подготовить репо, собрать образы, прогнать линтеры, запустить развертывание review окружения, прогнать jobs, миграции и init контейнеры). Получить RTT меньше минуты с удаленным окружением на (нашей) практике невозможно.
А эта скорость: код -> результат, это именно то для чего devops организовался, это его основное предназначение. И она напрямую конвертируется в скорость поставки фитч на прод и комфорт работы разработчика (которому не нужно больше держать в памяти контекст предыдущего запуска CI и сопоставлять его с изменениями, которые он уже успел написать вперед пока pipeline pending).
Вы забыли важный параграф про получение энергии посредством акреции вещества на черную дыру. В отличии от ТЯ синтеза с его приблизительно 1% mc^2 энерговыходом, акреция вещества на черную дыру дает в предельном случае приблизительно 42% mc^2. С учетом огромной разницы в энергоэффективности и доступности и черных дыр, и остатков звезд, можно ожидать так же значительного продления жизни на данном источнике энергии.
Не исключено что такое существование продлится даже не в 42 раза, а еще дольше. Ведь собирать энергию со столь огромной энергоустановки как звезда + панели вокруг неё - это чрезвычайно неэффективное занятие. Слишком мала излучаемая плотность энергии, требуются огромные площади панелей для поглащения этой энергии, отсюда недостатки в КПД и стоимости (=энергоемкости) обслуживания. А вот микроскопическая черная дыра могла бы быть упакована в компактную высокоэффективную энергоустановку.
С памятью все просто... Ну нет, с памятью все еще хуже. :)
Во-первых предложеное решение не сработает. Лимиты по памяти должны быть безальтернативно установлены. Иначе это грозит выселением всех подов с ноды или даже зависанием последней.
Во-вторых потребности в CPU гораздо проще определяются - смотришь график потребления CPU и выставляешь, и если нагрузка не меняется в 100 раз - у тебя все хорошо. С памятью так вообще не работает и сильно зависит от типа приложения. Одним ставишь лимит на 30% больше максимального RSS - и они работают как ни в чем ни бывало, например nginx. Другим ставить на 2000% больше максимального RSS в районе WSS - они стабильно и воспроизводимо падают, например postgres. Как формализовать установку лимитов по памяти, да так чтобы не тренироваться узнаванием "когда оно падает", до сих пор не знаю.
И еще кстати метрики CPU собираются как prometheus counter, а memory как gauge. А это значит что пропустить пик потребления CPU, который бы уперся в лимиты - невозможно, а по памяти - запросто (просто не попали и интервал "скребления", приходите "поскребсти" в следующих раз)
Неправильно тестите. Для этого есть команда type:
Если в сети существуют потери и заметный jitter (хотябы иногда), то почувствовав их на внешнем (VPN транспорт) tcp сеансе, tcp/ip стек машины считает, что в канале перегрузка и начинает уменьшать окно tcp (количество неподтвержденных / передаваемых_в_сей_момент фреймов). Это разумеется аффектит скорость внутрених сеансов. Но само по себе это не так страшно, если забыть о том, что протокол управления окном работает и для них тоже.
И так, последние мало того что они прямым образом «собрали» потери и джиттер от внешнего tcp сеанса — замедлились то тем же правилам. Так для них полоса пропускания канала (внешняя tcp сессия в которой они живут) стала уже, и они вынуждены вставать в очереди, увеличивая время rtt (время двойного прохода, посылки-подтверждения) в том числе на dst хостах для внутрених сеансов. Никто не ожидал, но вот опять: срабатывает протокол управления окном, скорость внутренних сеансов замедляется еще сильнее. И похоже и это не самое плохое.
А вот тут я уже немного вангую. Вероятно возможно какое-то стечение обстоятельств (используемых полос пропускания, имеющихся потерь и джитера), когда доступная полоса для внутрених сессий находится в какомто хрупком равновесии с возможностями внешней сессии, и все это работает относительно нормально. Но потом приходит возмущение, и все идет в полный разнос. С падением полос пропускания в ноль, задержек до десятков секунд. Это я последнее время наблюдаю используя tcp vpn до aws. Пинг по 30 секунд, зато нет потерь. Класс!
А что в случае внешнего udp/ip? Да как сказал «великий классик»: «ну потеря, так потеря», работаем дальше.
Такие MITM выкрутасы можно сделать ровно 1 раз:
Сертификат будет тут же сохранен пользователем.
Пользователь пойдет на страничку с certificate transparency логом и не обнаружит там этого сертификата.
После этого нелегальный сертификат выкладывается в публичный доступ, рядом ложится ссылка выше - кто угодно может ознакомиться с пруфами инцидента.
Из всего этого будет следовать - закрытый ключ скомпрометирован. Доверия этому УЦ больше нет. Все (кого интересует безопасность) массово поудаляют этот CA.
А кого не интересует - для того такой вопрос (Russian CA) просто не стоит. Большинство людей вообще спокойно пользуются ОС Шindoшs и смартфонами, которые в открытую сообщают о сливе информации впользу Васянов не дающих никаких гарантий и находящихся в авшорных юрисдикциях. Чего уж говорить про установку какого-то файлика в браузер, это вообще ерунда какая-то. :)
Это еще что.
Они недавно забанили Happy - в прошлом чемпиона мира по Warcraft3 и самого сильного игрока на текущий момент (например последний крупнейший международный турнир с участием сильнейших игроков он выигрыл с разгромным счетом 13:0, не отдав ни одной карты)
2033: Релиз проекта консорциума сетевых компаний, корпорации «Прогресса». В теле человека: тысячи микроскопических датчиков посылающих параметры организма в «центр», кибернетический орган по команде синтезирует ферменты, ГМО бактерии и вирусы точечно, без побочных эффектов решающие проблемы. Практическое бессмертие. По условиям контракта пользователь разрешает использование информации в не медицинских целях.
2039: Дифференциация уровня жизни измененных и обычных людей. Омоложение, не болеют, больший интеллект, творчески активнее, живут вечно. Законодательное ограничение рождаемости. Деградация инфраструктуры обычных людей: больницы, школы, ВУЗы… Социальные проблемы: трудности с трудоустройством, большая страховка, налоги… Маргинализация образа жизни обычных людей. Протесты не замечены, «они тут ненадолго».
2041: Прогресс в нейронных сетях, построение модели личности человека и способов её модификации.
2044: Первое дистанционное уничтожение террориста.
2049: Снова достигнута «маркетинговая полнота», монетизация любой информации о человеке закончилась. Не состоялась экстренная конференция по неправомерному применению системы для управления людьми, модифицированный автор разбился на древнем Харлее.
2050: Люди единогласно, самостоятельно приняли решение объединиться в государство «Прогресса».
2117: Исчезновение последнего обычного человека. Принудительная модификация, контроль за технологиями, фактически остановка прогресса. Всеобщая солидарность «против ИИ».
Это неплохо выглядит, когда оно написано на рекламном плакате.
А на деле, скорее всего, нас опять хотят «защитить» от свободы в использовании ПО.
Столлман приди — порядок наведи!