А как же очень удобная опция --unrestricted для menuentry, которая позволяет загрузить выбранный пункт, но для изменения параметров загрузки потребует пароль.
Еще в core.img можно интегрировать свой ключ, и тогда grub будет загружать только подписанные вами же ядра и initramfs. Смотрите опцию --pubkey у grub-install.
Или воспользоваться secure boot, прописать свои ключи, да и вообще отказаться от загрузчика. Или подписать grub своим сертификатом, чтобы uefi проверял подпись загрузчика, а загрузчик - подписи ядер и initramfs
Спасибо за ваш титанический труд по сохранению здоровья гиков. Позвольте добавить pull request.
В утилизации отходов кашицы из мягких тканей свиньи (в простонародье котлет) допущена неточность. Добавление сырого яйца подразумевает добавления только его внутренностей, а попавшие частички твердой оболочки, называемой скорлупой, желательно удалить.
И как рекомендации из личного опыта. К наполнителю из хлеба также можно добавить молоко. Дозировку следует выбирать таким образом, чтобы кашица из хлеба с молоком оббладала текстурой, сходной с текстурой мясной кашицы. А если дома остался зачерствевший хлеб (без плесени, это важно), то его можно измельчить до грубодисперсного порошка с размером частиц 0.1-0.5 мм, и нанести на все внешние поверхности диска перед обжариванием. Также данный порошок можно найти в продовольственном магазине под наименованием "сухари панировочные".
В следующую редакцию еще я хотел бы предложить внести рецепт пельменей, позволяющий как насытить руки полезными веществами, так и развить мелкую моторику.
Отвечу здесь же, потому что использую похожее решение.
Я использую или systemd unit, который перезапускается при падении туннеля с обычным ssh, не auto, или баш скрипт, который в просто в цикле дергает ssh с нужными параметрами. Но в случае с баш скриптом его надо руками запускать после перезагрузки системы.
Увы, для существования технаря деньги тоже нужны :)
Когда технарю хватает зарплаты на существование, а не на жизнь, жажда исследований сменяется жаждой найти деньги для жизни. Благо, в IT я нашел ту область, в которой я могу заниматься исследованиями и использовать свои знания, и получать при этом достойную зарплату.
Так что технарь лучше работет при наличии денег :)
Про слух про оптимальные 5 ядер я думаю в курсе все, кто использует pyspark :)
В идеале при регулярных расчетах надо все обвесить мониторингами потребления памяти, процессоров, смотреть, есть ли spill. И еще исходить из баланса времени расчета, ресурсов и человеческих договоренностей, ведь на кластере мы никогда не бываем в одиночестве.
При разовых расчетах всем хочется быстрее получить результат, но тут опять же надо учитывать тот баланс ресурсов, времени и загруженности кластера.
А чтобы не стоять в очереди, достаточно иметь один экзекутор, одно ядро и гигабайт памяти. Только вот зачем?
Для динамической аллокации еще полезно знать про опцию spark.dynamicAllocation.cachedExecutorIdleTimeout, потому что если экзекутор закэшировал данные, то по истечению executorIdleTimeout он не будет остановлен.
И указывать 20 гигабайт и 5 ядер - странная необоснованная практика. Например, я (тоже почти ничем не обоснованно, да) чаще использую 4 ядра и 10 гигабайт, и в 99% случаев этого достаточно.
Запрещаем авторизацию по паролю, оставляя только по ключу
Еще стоит проверить, что в конфиге явно указано KbdInteractiveAuthentication no или ChallengeResponseAuthentication no. Иначе такая команда может привести к удивительным результатам: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.com
Выключаем пользователя root
А это лучше делать не через правку /etc/passwd руками, а через sudo chsh -s /sbin/nologin root. И еще рекомендую посмотреть ключи --expire и --lock для команды passwd.
Это упрощение. Как минимум есть еще классический collect(). А проблемы с нехваткой памяти также можно легко получить и при неосторожном использовании методов для pyspark.DataFrame coalesce() или repartition()
К тому же можно сделать не toPandas().to_csv(), а записать датафрейм в hive или hdfs, например, а потом оттуда забрать данные.
берите в 5-10 раз больше памяти, чем занимают ваши данные;
А shuffle, возникающий при джойне, изменяет количество партиций до параметра spark.sql.shuffle.partitions, который по умолчанию 200.
Не все данные могут так просто влезть в память. И как раз настройка этого параметра позволяет не брать десятки гигабайт памяти на экзекутор, и pyspark сам разобьет датафреймы на более мелкие партиции.
По ядрам все просто: чем их больше, тем быстрее идут расчёты.
Но чем больше ядер на экзекутор, тем меньше памяти на ядро. И тем больше потоков при shuffle read/write, что тоже не всегда хорошо. Это палка о двух концах.
И если основная цель - это все же ускорить вычисления, то как минимум стоит задумываться о том, как партицированы данные при джойнах, чтобы избежать лишней передачи данных.
Были эксперименты с N-pair-mc Loss. На наших данных для этой задачи лучше всего себя показали BCE Loss и дообучение с ArcFaceLoss. Модель сейчас ResNet, и Swin Transformer в процессе оценки.
Если честно, пока особо не смотрели в сторону этого подхода. Было желание использовать обученную модель и для других задач, где есть много размеченных данных, поэтому вопрос с методом обучения особо и не возникал. Надеюсь в будущем, когда мы соберемся переобучать модели, будет время поэкспериментировать и попробовать новые подходы.
И это все?
А как же очень удобная опция --unrestricted для menuentry, которая позволяет загрузить выбранный пункт, но для изменения параметров загрузки потребует пароль.
Еще в core.img можно интегрировать свой ключ, и тогда grub будет загружать только подписанные вами же ядра и initramfs. Смотрите опцию --pubkey у grub-install.
Или воспользоваться secure boot, прописать свои ключи, да и вообще отказаться от загрузчика. Или подписать grub своим сертификатом, чтобы uefi проверял подпись загрузчика, а загрузчик - подписи ядер и initramfs
Спасибо за ваш титанический труд по сохранению здоровья гиков. Позвольте добавить pull request.
В утилизации отходов кашицы из мягких тканей свиньи (в простонародье котлет) допущена неточность. Добавление сырого яйца подразумевает добавления только его внутренностей, а попавшие частички твердой оболочки, называемой скорлупой, желательно удалить.
И как рекомендации из личного опыта. К наполнителю из хлеба также можно добавить молоко. Дозировку следует выбирать таким образом, чтобы кашица из хлеба с молоком оббладала текстурой, сходной с текстурой мясной кашицы. А если дома остался зачерствевший хлеб (без плесени, это важно), то его можно измельчить до грубодисперсного порошка с размером частиц 0.1-0.5 мм, и нанести на все внешние поверхности диска перед обжариванием. Также данный порошок можно найти в продовольственном магазине под наименованием "сухари панировочные".
В следующую редакцию еще я хотел бы предложить внести рецепт пельменей, позволяющий как насытить руки полезными веществами, так и развить мелкую моторику.
Отвечу здесь же, потому что использую похожее решение.
Я использую или systemd unit, который перезапускается при падении туннеля с обычным ssh, не auto, или баш скрипт, который в просто в цикле дергает ssh с нужными параметрами. Но в случае с баш скриптом его надо руками запускать после перезагрузки системы.
Увы, для существования технаря деньги тоже нужны :)
Когда технарю хватает зарплаты на существование, а не на жизнь, жажда исследований сменяется жаждой найти деньги для жизни. Благо, в IT я нашел ту область, в которой я могу заниматься исследованиями и использовать свои знания, и получать при этом достойную зарплату.
Так что технарь лучше работет при наличии денег :)
Про слух про оптимальные 5 ядер я думаю в курсе все, кто использует pyspark :)
В идеале при регулярных расчетах надо все обвесить мониторингами потребления памяти, процессоров, смотреть, есть ли spill. И еще исходить из баланса времени расчета, ресурсов и человеческих договоренностей, ведь на кластере мы никогда не бываем в одиночестве.
При разовых расчетах всем хочется быстрее получить результат, но тут опять же надо учитывать тот баланс ресурсов, времени и загруженности кластера.
А чтобы не стоять в очереди, достаточно иметь один экзекутор, одно ядро и гигабайт памяти. Только вот зачем?
Для динамической аллокации еще полезно знать про опцию
spark.dynamicAllocation.cachedExecutorIdleTimeout, потому что если экзекутор закэшировал данные, то по истечению executorIdleTimeout он не будет остановлен.И указывать 20 гигабайт и 5 ядер -
страннаянеобоснованная практика. Например, я (тоже почти ничем не обоснованно, да) чаще использую 4 ядра и 10 гигабайт, и в 99% случаев этого достаточно.Еще стоит проверить, что в конфиге явно указано
KbdInteractiveAuthentication noилиChallengeResponseAuthentication no. Иначе такая команда может привести к удивительным результатам:ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.comА это лучше делать не через правку
/etc/passwdруками, а черезsudo chsh -s /sbin/nologin root. И еще рекомендую посмотреть ключи--expireи--lockдля командыpasswd.Это упрощение. Как минимум есть еще классический collect(). А проблемы с нехваткой памяти также можно легко получить и при неосторожном использовании методов для pyspark.DataFrame coalesce() или repartition()
К тому же можно сделать не toPandas().to_csv(), а записать датафрейм в hive или hdfs, например, а потом оттуда забрать данные.
Не все данные могут так просто влезть в память. И как раз настройка этого параметра позволяет не брать десятки гигабайт памяти на экзекутор, и pyspark сам разобьет датафреймы на более мелкие партиции.
Но чем больше ядер на экзекутор, тем меньше памяти на ядро. И тем больше потоков при shuffle read/write, что тоже не всегда хорошо. Это палка о двух концах.
И если основная цель - это все же ускорить вычисления, то как минимум стоит задумываться о том, как партицированы данные при джойнах, чтобы избежать лишней передачи данных.
Добрый день!
Были эксперименты с N-pair-mc Loss. На наших данных для этой задачи лучше всего себя показали BCE Loss и дообучение с ArcFaceLoss. Модель сейчас ResNet, и Swin Transformer в процессе оценки.
Добрый день! Спасибо за интерес к статье.
Если честно, пока особо не смотрели в сторону этого подхода. Было желание использовать обученную модель и для других задач, где есть много размеченных данных, поэтому вопрос с методом обучения особо и не возникал. Надеюсь в будущем, когда мы соберемся переобучать модели, будет время поэкспериментировать и попробовать новые подходы.