Кроме sish упомянутого на пару комментов выше, стоит глянуть на frp. У sish свой оригинальный подход, а frp более функциональный и чуть ближе к ngrok. Вот тут хорошая подборка похожих инструментов https://github.com/anderspitman/awesome-tunneling.
А в трудовом договоре не надо ничего писать чтобы в подобных случаях "сотрудник" возмещал компании затраты на проведенные собеседования, услуги HR агентств и прочие ресурсы?
Ещё надо сказать что ML-проекты бывают разные, и например бразильцев из Federal University of Rio Grande волнует что у onnxruntime пайплайн в Github Actions занимает полтора часа, а не вот это всё :-).
(прислали гугл-форму с вопросами в рамках опроса контрибьюторов для исследования)
Однако, парадокс, там где результаты подзапроса используются как дополнительный набор данных (а результат берется отдельным проходом по таблице) - в explain нет слова subsquery, а там где результат подзапроса непосредственно используется для вывода (после фильтра) - это Subquery Scan :-).
Не взяли то наверное не из за ответа на джуновую задачку (очевидно что хардскиллы выше необходимого на джуновый уровень), а скорее из за неумения общаться и излишней самоуверенности?
Btw, в реальности предпочту решение через rank, так как на производительность в данном случае пофиг, да и индекса по salary скорее всего не будет. А решение с rank не делает полноценных подзапросов/джойнов, и делает в явном виде именно то что требуется в задаче без хаков.
Моя любимая задачка про оконные функции:
Есть файл (или табличка, как удобнее кандидату) куда пишутся значения показателей датчиков. Каждая запись содержит таймстемп, идентификатор датчика, и набор значений его показателей в указанный момент времени. Значения показателей меняются сильно реже интервала считывания. Нужно отфильтровать записи, в которых не происходит изменения значений показателей.
Область MLOps является еще достаточно молодой, и в ней до сих пор не существует единого золотого стандарта.
Я бы сказал что существует пара-тройка, airflow/kubeflow/или любое CI с графами задач, mlflow/wandb/свой велосипед, + dvc по вкусу, либо фуллстек решения databricks/azure?/AWS sagemaker. Но главное конечно - выстроенные процессы, политики, регламенты, и стайлгайды вокруг всего этого, и в статье неплохо описано что они должны покрывать. Но все равно стоит поизучайть доклады по жизненному циклу моделей с Data fest'ов ODS (кажется по ним уже можно сказать что общее понимание как жить mlops инженеру, "золотой стандарт", уже сложилось), да и в целом много информации на Хабре и в интернете на эту тему. А из "300 инструментов интеграции" надо определиться для чего инструменты нужны, ну и, скажем, если включать библиотеки как в посте на картинке, то штук 200 нужных инструментов освоить не такая уж проблема.
Ролик был виральный, как школьница в магазине домашку делала утащив планшет под прилавок. А продавец вместо того чтоб выгнать - поставил ей стул, геймерский.
Проверил - аккаунт ещё живой. Даже пароль почти с первого раза вспомнил (только оно попросило привязать телефон).
Из всей истории - только пара сообщений 2017 года. Старую историю ещё при переезде в мэйл продолбали, жалко :-(. Но вообще она у меня где-то на DVD-шках в кладовке забэкаплена, поищу повспоминаю через лет десять.
Подпись должна идти вместе с образом, а для ее проверки достаточно знать используемый публичный ключ... но Docker Inc всё ещё "We are working on integrating signature validation into our image pull and build processes. This will ensure that all Docker Official Images are verified before use, providing an additional layer of security for our users." (линк), так что проверять пока нечего.
→ docker trust inspect ubuntu:latest --pretty
Signatures for ubuntu:latest
SIGNED TAG DIGEST SIGNERS latest 3f85b7caad41a95462cf5b787d8a04604c8262cdcdf9a472b8c52ef83375fe15 (Repo Admin)
Концепция "всё есть 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" может значительно улучшить безопасность и гибкость системы за счет более точного контроля над тем, кто и как может взаимодействовать с ресурсами системы. Однако реализация такого подхода требует сложного дизайна и администрирования, а также может потребовать от разработчиков и пользователей изменения привычного подхода к взаимодействию с системой.
Кроме sish упомянутого на пару комментов выше, стоит глянуть на frp. У sish свой оригинальный подход, а frp более функциональный и чуть ближе к ngrok. Вот тут хорошая подборка похожих инструментов https://github.com/anderspitman/awesome-tunneling.
А в трудовом договоре не надо ничего писать чтобы в подобных случаях "сотрудник" возмещал компании затраты на проведенные собеседования, услуги HR агентств и прочие ресурсы?
Fake news на Хабре?
Как-то долго. А, голая макось... Ну норм, но зачем..?
Ещё надо сказать что ML-проекты бывают разные, и например бразильцев из Federal University of Rio Grande волнует что у onnxruntime пайплайн в Github Actions занимает полтора часа, а не вот это всё :-).
(прислали гугл-форму с вопросами в рамках опроса контрибьюторов для исследования)
Я про то что GPD Win Mini нормально входит в нижний боковой карман на джинсовых шортах например)
Однако, парадокс, там где результаты подзапроса используются как дополнительный набор данных (а результат берется отдельным проходом по таблице) - в explain нет слова subsquery, а там где результат подзапроса непосредственно используется для вывода (после фильтра) - это Subquery Scan :-).
Лол, пока читал комменты забыл что в статье это решение приведено :-)
(с подачей "и это не то!!!" вместо объяснения про сортировку просто не обратил внимания на это решение)
Задание со звёздочкой для оригинальной задачи (про зарплаты) - как решить её через оконные функции, но без сортировки.
Не взяли то наверное не из за ответа на джуновую задачку (очевидно что хардскиллы выше необходимого на джуновый уровень), а скорее из за неумения общаться и излишней самоуверенности?
Btw, в реальности предпочту решение через rank, так как на производительность в данном случае пофиг, да и индекса по salary скорее всего не будет. А решение с rank не делает полноценных подзапросов/джойнов, и делает в явном виде именно то что требуется в задаче без хаков.
Моя любимая задачка про оконные функции:
Есть файл (или табличка, как удобнее кандидату) куда пишутся значения показателей датчиков. Каждая запись содержит таймстемп, идентификатор датчика, и набор значений его показателей в указанный момент времени. Значения показателей меняются сильно реже интервала считывания. Нужно отфильтровать записи, в которых не происходит изменения значений показателей.
Я бы сказал что существует пара-тройка, airflow/kubeflow/или любое CI с графами задач, mlflow/wandb/свой велосипед, + dvc по вкусу, либо фуллстек решения databricks/azure?/AWS sagemaker. Но главное конечно - выстроенные процессы, политики, регламенты, и стайлгайды вокруг всего этого, и в статье неплохо описано что они должны покрывать. Но все равно стоит поизучайть доклады по жизненному циклу моделей с Data fest'ов ODS (кажется по ним уже можно сказать что общее понимание как жить mlops инженеру, "золотой стандарт", уже сложилось), да и в целом много информации на Хабре и в интернете на эту тему. А из "300 инструментов интеграции" надо определиться для чего инструменты нужны, ну и, скажем, если включать библиотеки как в посте на картинке, то штук 200 нужных инструментов освоить не такая уж проблема.
Нормально оно в карман влазит, уже чуть не постирал.
Не понимаю нафига нужны миники на интелах, когда со встройкой AMD любые игры идут.
Ролик был виральный, как школьница в магазине домашку делала утащив планшет под прилавок. А продавец вместо того чтоб выгнать - поставил ей стул, геймерский.
Вот! Вот оно, настоящее пиратство!) Крадут приложения прямо из магазина!!! :-)
Крошить без оглядки это IDKFA.
Проверил - аккаунт ещё живой. Даже пароль почти с первого раза вспомнил (только оно попросило привязать телефон).
Из всей истории - только пара сообщений 2017 года. Старую историю ещё при переезде в мэйл продолбали, жалко :-(. Но вообще она у меня где-то на DVD-шках в кладовке забэкаплена, поищу повспоминаю через лет десять.
Подпись должна идти вместе с образом, а для ее проверки достаточно знать используемый публичный ключ... но Docker Inc всё ещё "We are working on integrating signature validation into our image pull and build processes. This will ensure that all Docker Official Images are verified before use, providing an additional layer of security for our users." (линк), так что проверять пока нечего.
→ docker trust inspect ubuntu:latest --pretty
Signatures for ubuntu:latest
SIGNED TAG DIGEST SIGNERS
latest 3f85b7caad41a95462cf5b787d8a04604c8262cdcdf9a472b8c52ef83375fe15 (Repo Admin)
Administrative keys for ubuntu:latest
Repository Key: 8273733f491f362bb36710fd8a99f78c3fbaecd8d09333985c76f1064b80760f
Root Key: 1f9bc7ae6335ae41ee03e983c0e31303901be567b4cdb3fc7c7363f0591128ff
Выглядит так, как будто подписи тут нет.
Плохой способ - ключ шифрования мог быть слабый сгенерерирован, или одинаковый на всю серию. Надо выводить из строя сами чипы памяти, без вариантов.
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" может значительно улучшить безопасность и гибкость системы за счет более точного контроля над тем, кто и как может взаимодействовать с ресурсами системы. Однако реализация такого подхода требует сложного дизайна и администрирования, а также может потребовать от разработчиков и пользователей изменения привычного подхода к взаимодействию с системой.