Концепция "всё есть capability" (everything is a capability) представляет собой подход к дизайну систем, где основным элементом является понятие "способности" или "права" (capability), которое определяет, что именно может делать программа или процесс в системе. Эта идея фокусируется на безопасности и изолировании, позволяя контролировать доступ к ресурсам на более тонком уровне, чем традиционные модели, основанные на разграничении доступа (например, Unix-подобные права на файлы).
В контексте "всё есть capability":
1. **Определение**: Capability — это ключ или токен, который предоставляет держателю право на выполнение определенной операции или доступ к ресурсу. Важной особенностью является то, что capability конкретизирует и минимизирует права, тем самым предотвращая злоупотребления и ограничивая возможные точки сбоя.
2. **Ресурсы и операции**: В системе, основанной на capabilities, всё, что требует контроля доступа — файлы, устройства, сетевые соединения и даже более абстрактные действия, такие как возможность перезагрузки системы — представляется через capability. Это означает, что для любого действия или доступа к ресурсу существует соответствующая capability.
3. **Делигирование и распространение**: Capability можно передавать от одного процесса к другому, позволяя создавать тонко настроенные цепочки доверия и делегирования прав. Это делает систему гибкой и позволяет строить сложные многоуровневые архитектуры безопасности.
4. **Изоляция и безопасность**: Использование capability обеспечивает естественную изоляцию между компонентами системы, поскольку каждый компонент имеет доступ только к тем ресурсам, для которых у него есть явно выданные права. Это снижает риск несанкционированного доступа и предотвращает множество атак, связанных с повышением привилегий.
5. **Примеры систем**: Некоторые операционные системы и платформы, например, Genode OS Framework или Google's Fuchsia, используют концепции, близкие к идеям capability для обеспечения безопасности и изоляции.
Концепция "всё есть capability" может значительно улучшить безопасность и гибкость системы за счет более точного контроля над тем, кто и как может взаимодействовать с ресурсами системы. Однако реализация такого подхода требует сложного дизайна и администрирования, а также может потребовать от разработчиков и пользователей изменения привычного подхода к взаимодействию с системой.
Нужно лучше курить матчасть против которой ведёшь риторику, и быть дотошным в тезизах, а так статья хорошая, молодец. Покури ещё концепцию "всё есть capability".
Сложная тема, чтобы представить как оно работает в случае cluster mode или spark submit (не будет ли каких-то side effect от перезапуска драйвера), нужно как минимум понимать как взаимодействуют yarn/driver/applicationmaster.
Помимо прочего, после завершения JVM-процесса драйвера необходимо корректно завершить все открытые соединения с ним. Для этого достаточно вызвать метод shutdown() у экземпляра класса JavaGateway
А нельзя просто shutdown позвать без всех извращений с ручной отправкой команд?
Фиг знает, иногда достаточно просто задать пару вопросов из того списка чтобы определить примерный уровень кандидата, а выдать кастомную задачку надо ещё уметь. Про пару pod'ов общающихся через интернет - слишком общий вопрос, который под собой вероятно имеет какую-то конкретную рабочую ситуацию, и кандидат должен постараться вытянуть из интервьюера достаточное количество подробностей чтобы о чем-то там рассуждать. Тоже впрочем полезный скилл, который имеет смысл проверять на собеседовании. Но для "понимания как кандидат думает" лучше дать четкую задачку на логику.
Мой пойнт в том, что задача не базовая. Оригинально nginx не очень рассчитан на то, чтобы работать в контейнеризированном окружении, а его настройка (даже без контейнеризации) это довольно комплексная задача, требующая понимания многих аспектов работы ОС и сети. Но, если речь про кубер, то нормальный кандидат как минимум должен спросить "эм, вы имеете ввиду настроить ingress?", ну и другие требования уточнить. Запустить пачку pod'ов с nginx'ом != развернуть nginx в кубере.
Если речь не про ingress, то вопрос должен быть "а что именно этот nginx должен делать?". И там даже для раздачи статического контента очень много о чем можно поговорить, кроме использования kubectl и определений ресурсов в YAML.
Нет смысла тестироваться на этой задаче в исходной постановке, ни на русском ни на английском. Она многократно встречается в датасетах на которых эти сетки обучались. Но стоит отметить что во многих бенчмарках используются подобные задачи, правда обычно чуть более простые.
Очень больно бывает когда в компании неожиданно падает мэнеджед кубер, а девопс инженеры считают разворачивание nginx базовой задачей и не знают с какой стороны к лежачему куберу подойти. Впрочем не обязательно ломать сам кубер, можно просто сервис сломанный дать и спросить как его чинить вообще.
Фиг знает, молодцы конечно, но подано это всё немного с преувеличениями. Году в 2013м трогал репозиторий сравнимого размера, на предмет перехода с svn. Размер чекаута основного бранча там был поменьше наверное на порядок, общий размер репы был под 100гб. При грамотной настройке клиентской системы git с полным репозиторием работал довольно шустро, хоть и не без проблем, и какая-то часть разработчиков даже пользовалась git-svn, правда только с нужными ветками и обычно используя sparse checkout. В итоге там решили писать свою систему контроля версий имени этого репозитория :-).
если авторы хотят сделать хорошее для других обитателей планеты, то странно ожидать за это вознаграждения
Авторы хотят заниматься любимым делом - разработкой открытого ПО, не в рамках интересов какой-то одной компании. И ищут пути монетизации своего труда. Это их право, не нужно указывать им что им делать.
интеллектуальная собственность — это фикция. В том числе потому, что её невозможно украсть
Не собираюсь спорить про формулировки, но поясню что имел ввиду: делаешь прошивку, говоришь "я разработал эту прошивку и имею все необходимые авторские права, делайте дальше что хотите" == украл интеллектуальную собственность. Возможно формулировка некорректна, не буду спорить.
доработал его для моего клиента и передал ему с соблюдением лицензии открытого проекта, то о каких нарушениях может идти речь
А клиент потом передавая свой продукт конечному потребителю будет соблюдать условия оригинальной лицензии?
Но вы, являясь разработчиком открытого ПО, получив вознаграждение в таком случае - всё равно молодец, об этом говорится в статье.
Особенно, если доработки отдали в апстрим, и занимаетесь поддержкой своих открытых библиотек, и не подписывали с заказчиком договоров по которым вам для выполнения заказа нужно нарушать чужие авторские права и условия лицензий.
Плохой способ - ключ шифрования мог быть слабый сгенерерирован, или одинаковый на всю серию. Надо выводить из строя сами чипы памяти, без вариантов.
Hidden text
Концепция "всё есть capability" (everything is a capability) представляет собой подход к дизайну систем, где основным элементом является понятие "способности" или "права" (capability), которое определяет, что именно может делать программа или процесс в системе. Эта идея фокусируется на безопасности и изолировании, позволяя контролировать доступ к ресурсам на более тонком уровне, чем традиционные модели, основанные на разграничении доступа (например, Unix-подобные права на файлы).
В контексте "всё есть capability":
1. **Определение**: Capability — это ключ или токен, который предоставляет держателю право на выполнение определенной операции или доступ к ресурсу. Важной особенностью является то, что capability конкретизирует и минимизирует права, тем самым предотвращая злоупотребления и ограничивая возможные точки сбоя.
2. **Ресурсы и операции**: В системе, основанной на capabilities, всё, что требует контроля доступа — файлы, устройства, сетевые соединения и даже более абстрактные действия, такие как возможность перезагрузки системы — представляется через capability. Это означает, что для любого действия или доступа к ресурсу существует соответствующая capability.
3. **Делигирование и распространение**: Capability можно передавать от одного процесса к другому, позволяя создавать тонко настроенные цепочки доверия и делегирования прав. Это делает систему гибкой и позволяет строить сложные многоуровневые архитектуры безопасности.
4. **Изоляция и безопасность**: Использование capability обеспечивает естественную изоляцию между компонентами системы, поскольку каждый компонент имеет доступ только к тем ресурсам, для которых у него есть явно выданные права. Это снижает риск несанкционированного доступа и предотвращает множество атак, связанных с повышением привилегий.
5. **Примеры систем**: Некоторые операционные системы и платформы, например, Genode OS Framework или Google's Fuchsia, используют концепции, близкие к идеям capability для обеспечения безопасности и изоляции.
Концепция "всё есть capability" может значительно улучшить безопасность и гибкость системы за счет более точного контроля над тем, кто и как может взаимодействовать с ресурсами системы. Однако реализация такого подхода требует сложного дизайна и администрирования, а также может потребовать от разработчиков и пользователей изменения привычного подхода к взаимодействию с системой.
Нужно лучше курить матчасть против которой ведёшь риторику, и быть дотошным в тезизах, а так статья хорошая, молодец. Покури ещё концепцию "всё есть capability".
Сложная тема, чтобы представить как оно работает в случае cluster mode или spark submit (не будет ли каких-то side effect от перезапуска драйвера), нужно как минимум понимать как взаимодействуют yarn/driver/applicationmaster.
А нельзя просто shutdown позвать без всех извращений с ручной отправкой команд?
(сорян, промазал полем ответа)
Чем в таком кейсе не подошёл dynamic allocation?
И что помешало разбить процесс на несколько задач (на уровне оркестратора)?
Интересный факт, фанаты эппла и не подозревают о возможности подключения внешней видеокарты (и о том что на apple silicon такой возможности нет :-) ).
Вместо этого у эппла есть возможность продать фичу подключения нескольких мониторов :-).
В первом абзаце так много восторженных баззвордов заказанных маркетологами, что дальше уже не хочется читать.
Про подачу - куча воды и реклама телеграм канала в конце. В блоге компании. Туш.
Фиг знает, иногда достаточно просто задать пару вопросов из того списка чтобы определить примерный уровень кандидата, а выдать кастомную задачку надо ещё уметь. Про пару pod'ов общающихся через интернет - слишком общий вопрос, который под собой вероятно имеет какую-то конкретную рабочую ситуацию, и кандидат должен постараться вытянуть из интервьюера достаточное количество подробностей чтобы о чем-то там рассуждать. Тоже впрочем полезный скилл, который имеет смысл проверять на собеседовании. Но для "понимания как кандидат думает" лучше дать четкую задачку на логику.
Обычно как минимум один раз на каждую организацию, которая решает использовать Kubernetes :-).
Мой пойнт в том, что задача не базовая. Оригинально nginx не очень рассчитан на то, чтобы работать в контейнеризированном окружении, а его настройка (даже без контейнеризации) это довольно комплексная задача, требующая понимания многих аспектов работы ОС и сети. Но, если речь про кубер, то нормальный кандидат как минимум должен спросить "эм, вы имеете ввиду настроить ingress?", ну и другие требования уточнить. Запустить пачку pod'ов с nginx'ом != развернуть nginx в кубере.
Если речь не про ingress, то вопрос должен быть "а что именно этот nginx должен делать?". И там даже для раздачи статического контента очень много о чем можно поговорить, кроме использования kubectl и определений ресурсов в YAML.
Нет смысла тестироваться на этой задаче в исходной постановке, ни на русском ни на английском. Она многократно встречается в датасетах на которых эти сетки обучались. Но стоит отметить что во многих бенчмарках используются подобные задачи, правда обычно чуть более простые.
Это какое-то странное умение. Пример в указанной доке использует nginx как hello world. С тем же успехом там мог быть любой другой сервис.
Очень больно бывает когда в компании неожиданно падает мэнеджед кубер, а девопс инженеры считают разворачивание nginx базовой задачей и не знают с какой стороны к лежачему куберу подойти. Впрочем не обязательно ломать сам кубер, можно просто сервис сломанный дать и спросить как его чинить вообще.
Фиг знает, молодцы конечно, но подано это всё немного с преувеличениями. Году в 2013м трогал репозиторий сравнимого размера, на предмет перехода с svn. Размер чекаута основного бранча там был поменьше наверное на порядок, общий размер репы был под 100гб. При грамотной настройке клиентской системы git с полным репозиторием работал довольно шустро, хоть и не без проблем, и какая-то часть разработчиков даже пользовалась git-svn, правда только с нужными ветками и обычно используя sparse checkout. В итоге там решили писать свою систему контроля версий имени этого репозитория :-).
Впрочем это не всегда важно, и один из вариантов - действительно пойти в корпорацию, о чем в статье тоже говорится.
Нет.
Авторы хотят заниматься любимым делом - разработкой открытого ПО, не в рамках интересов какой-то одной компании. И ищут пути монетизации своего труда. Это их право, не нужно указывать им что им делать.
Не собираюсь спорить про формулировки, но поясню что имел ввиду: делаешь прошивку, говоришь "я разработал эту прошивку и имею все необходимые авторские права, делайте дальше что хотите" == украл интеллектуальную собственность. Возможно формулировка некорректна, не буду спорить.
А клиент потом передавая свой продукт конечному потребителю будет соблюдать условия оригинальной лицензии?
Но вы, являясь разработчиком открытого ПО, получив вознаграждение в таком случае - всё равно молодец, об этом говорится в статье.
Особенно, если доработки отдали в апстрим, и занимаетесь поддержкой своих открытых библиотек, и не подписывали с заказчиком договоров по которым вам для выполнения заказа нужно нарушать чужие авторские права и условия лицензий.