Forwarded from Tensor Banana
Треним лоры для qwen/qwen-edit в fp8 в musubi-tuner под виндой
Лоры для qwen-image также работают в qwen-image-edit.
Musubi также поддерживает тренировку qwen-edit с 3 картинками: до, после и маска. Подробнее тут (я пока не тестил): https://github.com/kohya-ss/musubi-tuner/blob/main/docs/qwen_image.md
Рекомендую тренить в разрешении 1024x1024, 3000 шагов, затем дополнительно в 1300x1300 еще 1000 шагов. Так будет более универсальная поддержка разных разрешений на выходе. За пару дней натренил 5 лор (стиль, концепт, персонажи), выкладываю 2. Для лоры на лицо можно использовать селфи, за 5000 шагов квен выучивает лицо очень неплохо.
1000-2000 шагов для квена - это слишком мало, надо 3000 минимум и на стиль и на персонажа. За ночь (~10 часов) у меня выходит 4000-5000 шагов на 3090 при 1024. На 3060 - в 16 раз медленнее.
Датасет:
20-100 картинок с txt описанием в хорошем качестве и разрешении. В каком разрешении треним, в таком и делаем инференс для максимального качества. Список разрешений ваших картинок выводится в консоли в начале тренировки.
Для лоры на персонажа:
- датасет 30-40 картинок
- фото не мелкие, разные ракурсы. Можно селфи.
- если будут шумные (зерно) - на выходе тоже получите шумные
- 3000 шагов минимум, я тренил 5000 шагов, 1024x1024 + 1300x1300
- в txt описании лучше делать полные описания. Уникальное имя (A13xandra) + в чем одета и что делает.
# Требования:
32 RAM + 24 GB vram (на 12 слишком медленно)
musubi не поддерживает nf4. Если у вас нет 24GB - попробуйте https://github.com/Nerogar/OneTrainer, он поддерживает nf4 и работает с виндой.
# Установка
модельки (нужны именно bf16 версии):
https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/blob/main/split_files/diffusion_models/qwen_image_bf16.safetensors
https://huggingface.co/Qwen/Qwen-Image/blob/main/vae/diffusion_pytorch_model.safetensors
https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/blob/main/split_files/text_encoders/qwen_2.5_vl_7b.safetensors
# Тренировка:
- мой toml файл датасета: https://github.com/Mozer/comfy_stuff/blob/main/musubi/dataset_hand_grab.toml
- комманды запуска (в пост не влезли): https://github.com/Mozer/comfy_stuff/blob/main/musubi/musubi_qwen_commands.txt
- при изменении разрешения тренировки надо заново создать кэш vae
# Инференс:
для qwen-image рекомендую сэмплер dpmpp_2m + beta либо res_2s + bong_tangent. Они показывают лучшую реалистичность
832x1248 или 1056x1600, cfg 3.0, 25 steps
для qwen-image-edit я не нашел реалистичных сэмплеров, пока юзаю dpmpp_2m + beta.
ВФ для qwen-edit: https://github.com/Mozer/comfy_stuff/blob/main/workflows/qwen_edit_hand_grab_25_steps.json
lightning лора 4, 8 steps сильно ухудшает качество и реализм, по возможности не используйте её. Но будет медленно, 20-25 шагов - оптимально (2 минуты на картинку для qwen-edit).
Мои qwen лоры:
- marat safin style (стиль под пленку): https://civitai.com/models/1894150?modelVersionId=2353000
- hand grab (POV рука трогает объект): https://civitai.com/models/2081019?modelVersionId=2354652
- лора на русский язык еще тренится
Лоры для qwen-image также работают в qwen-image-edit.
Musubi также поддерживает тренировку qwen-edit с 3 картинками: до, после и маска. Подробнее тут (я пока не тестил): https://github.com/kohya-ss/musubi-tuner/blob/main/docs/qwen_image.md
Рекомендую тренить в разрешении 1024x1024, 3000 шагов, затем дополнительно в 1300x1300 еще 1000 шагов. Так будет более универсальная поддержка разных разрешений на выходе. За пару дней натренил 5 лор (стиль, концепт, персонажи), выкладываю 2. Для лоры на лицо можно использовать селфи, за 5000 шагов квен выучивает лицо очень неплохо.
1000-2000 шагов для квена - это слишком мало, надо 3000 минимум и на стиль и на персонажа. За ночь (~10 часов) у меня выходит 4000-5000 шагов на 3090 при 1024. На 3060 - в 16 раз медленнее.
Датасет:
20-100 картинок с txt описанием в хорошем качестве и разрешении. В каком разрешении треним, в таком и делаем инференс для максимального качества. Список разрешений ваших картинок выводится в консоли в начале тренировки.
Для лоры на персонажа:
- датасет 30-40 картинок
- фото не мелкие, разные ракурсы. Можно селфи.
- если будут шумные (зерно) - на выходе тоже получите шумные
- 3000 шагов минимум, я тренил 5000 шагов, 1024x1024 + 1300x1300
- в txt описании лучше делать полные описания. Уникальное имя (A13xandra) + в чем одета и что делает.
# Требования:
32 RAM + 24 GB vram (на 12 слишком медленно)
На 3090-24GB:
768x768 block_swap 0, 22.6 vram, 4.17 s/it
1024x1024 block_swap 0, 23.9 vram, 8.50 s/it
1300x1300 block_swap 8, 24.2 vram, 16.41 s/it
На 3060-12GB:
1024x1024 block_swap 40, 11.8 vram, 140.0 s/it
musubi не поддерживает nf4. Если у вас нет 24GB - попробуйте https://github.com/Nerogar/OneTrainer, он поддерживает nf4 и работает с виндой.
# Установка
git clone https://github.com/kohya-ss/musubi-tuner
cd musubi-tuner
conda create musubi
conda activate musubi
(musubi) C:\DATA\SD\musubi-tuner>pip install -e
модельки (нужны именно bf16 версии):
https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/blob/main/split_files/diffusion_models/qwen_image_bf16.safetensors
https://huggingface.co/Qwen/Qwen-Image/blob/main/vae/diffusion_pytorch_model.safetensors
https://huggingface.co/Comfy-Org/Qwen-Image_ComfyUI/blob/main/split_files/text_encoders/qwen_2.5_vl_7b.safetensors
# Тренировка:
- мой toml файл датасета: https://github.com/Mozer/comfy_stuff/blob/main/musubi/dataset_hand_grab.toml
- комманды запуска (в пост не влезли): https://github.com/Mozer/comfy_stuff/blob/main/musubi/musubi_qwen_commands.txt
- при изменении разрешения тренировки надо заново создать кэш vae
# Инференс:
для qwen-image рекомендую сэмплер dpmpp_2m + beta либо res_2s + bong_tangent. Они показывают лучшую реалистичность
832x1248 или 1056x1600, cfg 3.0, 25 steps
для qwen-image-edit я не нашел реалистичных сэмплеров, пока юзаю dpmpp_2m + beta.
ВФ для qwen-edit: https://github.com/Mozer/comfy_stuff/blob/main/workflows/qwen_edit_hand_grab_25_steps.json
lightning лора 4, 8 steps сильно ухудшает качество и реализм, по возможности не используйте её. Но будет медленно, 20-25 шагов - оптимально (2 минуты на картинку для qwen-edit).
Мои qwen лоры:
- marat safin style (стиль под пленку): https://civitai.com/models/1894150?modelVersionId=2353000
- hand grab (POV рука трогает объект): https://civitai.com/models/2081019?modelVersionId=2354652
- лора на русский язык еще тренится
Forwarded from Agentic World
Векторные базы - классная штука, постарался сделать общий обзор в виде статьи на хабре на все, что сейчас представлено на рынке. Упор через призму RAG и AI-агентов, на все ушла пара бессонных ночей, но вышло, кажется, вполне неплохо.
В статье - про эмбединги, требования к векторным базам, инструмент бенчмаркинга, про индексы и сами базы.
https://habr.com/ru/articles/961088/
В статье - про эмбединги, требования к векторным базам, инструмент бенчмаркинга, про индексы и сами базы.
https://habr.com/ru/articles/961088/
Хабр
Выбираем векторную БД для AI-агентов и RAG: большой обзор баз данных и поиск смысла
В этой статье я сделал обзор основных векторных баз данных: Milvus, Qdrant, Weaviate, ChromaDB, pgvector, Redis, pgvectorscale, LanceDB, ClickHouse, Vespa, Marqo, ElasticSearch. Если вы запутались в...
Forwarded from Женя Янченко
Поговорим про обратную совместимость?
Применительно к REST API обратная совместимость означает, что новая версия бэка может принимать запросы от клиентов, которые ещё не обновились.
Представьте, что мы добавляем новую фичу, и при этом меняется контракт API.
Какие изменения НЕ сломают обратную совместимость:
🟢 Добавление нового эндпойнта
Старые клиенты просто о нем не знают, соответственно он им не помешает.
🟢 Добавление необязательных полей в ДТО запросов
🟢 Добавление полей с новыми именами в ДТО ответов
Тут нет 100% гарантии, так как нужно, чтобы клиенты игнорировали неизвестные поля, но обычно это так.
🌟 🌟 🌟
Какие изменения СЛОМАЮТ обратную совместимость:
🔴 Изменение типа данных (было число, теперь строка)
🔴 Изменение формата даты-времени (было "DD/MM/YY", стало "YYYY-MM-DD")
🔴 Удаление полей из ДТО ответа
Но эти изменения ещё не самое страшное. С ними клиент скорее всего упадет на первом же изменившемся запросе, его разработчики сразу придут к нам (или исправят у себя).
🔴 Очень опасным является изменение семантики поля без смены имени. Например, было поле
Решение простое: если меняется смысл, то заводим новое поле, например,
🟡 Добавление нового значения в enum — с осторожностью. Мы не знаем, как написаны клиенты нашего REST API: клиент может упасть при парсинге нового неизвестного значения enum-а или новое значение может вызвать баг в логике.
🌟 🌟 🌟
Если нам нужно внести "ломающие" изменения, то используем версионирование, то есть заводим новый эндпойнт с
- новые клиенты ходят на
- старые клиенты продолжают спокойно ходить на
🌟 🌟 🌟
🤔 Версионировать весь API или отдельные эндпойнты?
Новая версия всего API на каждый чих чревата тем, что мы расплодим кучу почти одинаковых контроллеров, и все старые версии будут висеть техдолгом.
➡️ Поэтому новую версию всего API могут использовать, когда этот API предназначен для внешних пользователей, например, клиентов/партнеров. Для новой версии копят набор изменений и выкатывают разом.
➡️ Версионирование отдельных эндпойнтов удобно при внутренних взаимодействиях (свой фронтенд, соседний микросервис).
🌟 🌟 🌟
🤔 Нужно ли вообще поддерживать обратную совместимость со своим фронтендом? Мы же сами вносим изменения, можем их внести и на бэке и на фронте.
Это зависит от процесса релиза.
Даже если изменения на бэке и фронте сделаны в рамках одного спринта или дождались друг друга, то есть еще вопрос деплоя. Если новая версия бэка задеплоится на минутку раньше новой версии фронта, то пользователи, выполняющие запросы в эту минутку, столкнутся с ошибками.
Если вопрос с пользователями тоже решен, то можно ломать одновременно 😃
⚡️ Если меняете контракт между микросервисами внутри бэка, то дважды проверьте, что на этот эндпойнт больше никто не ходит.
У вас на проекте поддерживают обратную совместимость с фронтендом?
🦆 — да
🐼 — обычно нет, вносим изменения одновременно
Применительно к REST API обратная совместимость означает, что новая версия бэка может принимать запросы от клиентов, которые ещё не обновились.
Представьте, что мы добавляем новую фичу, и при этом меняется контракт API.
Какие изменения НЕ сломают обратную совместимость:
Старые клиенты просто о нем не знают, соответственно он им не помешает.
Тут нет 100% гарантии, так как нужно, чтобы клиенты игнорировали неизвестные поля, но обычно это так.
Какие изменения СЛОМАЮТ обратную совместимость:
Но эти изменения ещё не самое страшное. С ними клиент скорее всего упадет на первом же изменившемся запросе, его разработчики сразу придут к нам (или исправят у себя).
total, куда записывалась сумма без НДС. Затем логика поменялась, теперь мы возвращаем сумму с НДС. Если мы оставим старое имя total с новым значением, то внешне контракт тот же, но внутри логика нарушится, а это самые коварные баги 😱Решение простое: если меняется смысл, то заводим новое поле, например,
totalWithVAT.Если нам нужно внести "ломающие" изменения, то используем версионирование, то есть заводим новый эндпойнт с
/v2 в пути. Теперь:- новые клиенты ходят на
/v2- старые клиенты продолжают спокойно ходить на
/v1 (а мы им мягко напоминаем, что покой нам только снится, поддержка /v1 будет прекращена через N месяцев, переходите на /v2)🤔 Версионировать весь API или отдельные эндпойнты?
Новая версия всего API на каждый чих чревата тем, что мы расплодим кучу почти одинаковых контроллеров, и все старые версии будут висеть техдолгом.
🤔 Нужно ли вообще поддерживать обратную совместимость со своим фронтендом? Мы же сами вносим изменения, можем их внести и на бэке и на фронте.
Это зависит от процесса релиза.
Например, на одном проекте у нас реализация бэка часто шла с опережением фронта, а подход к организации воркфлоу в Git не допускал долгоживущих веток. То есть бэк раскатывался, когда он сделан и протестирован, даже если фронт ещё не сделан. Соответственно мы использовали на бэке фича-флаги и поддерживали обратную совместимость. Когда фронт подтягивался, выпиливали устаревшее.
Даже если изменения на бэке и фронте сделаны в рамках одного спринта или дождались друг друга, то есть еще вопрос деплоя. Если новая версия бэка задеплоится на минутку раньше новой версии фронта, то пользователи, выполняющие запросы в эту минутку, столкнутся с ошибками.
Если вопрос с пользователями тоже решен, то можно ломать одновременно 😃
У вас на проекте поддерживают обратную совместимость с фронтендом?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Женя Янченко
Сейчас много говорят про собесы, и я решила поделиться одним лайфхаком общения с рекрутером.
Часто к общению с рекрутером/HR относятся формально: показать, что соответствуешь вакансии, узнать базовые моменты про оформление, ИТ-аккредитацию и всё.
Но рекрутера можно и нужно рассматривать как источник дополнительной информации, которая поможет пройти собес.
🤍 Например, можно подробнее расспросить про техническое интервью:
В худшем случае рекрутер просто не ответит, но часто они охотно рассказывают.
🤍 Ещё у рекрутера можно спросить, что важно нанимающему и почему отказали другим кандидатам.
Например, я наступила на такие грабли. Собесилась на позицию менеджера нескольких команд, аналогичную моей текущей. В вакансии были расписаны только менеджерские обязанности и требования соответственно про управленческий опыт🧑💼
Ок, в самопрезентации делаю акцент на этом. Вижу скепсис на лице нанимающего. Уточняю и получаю ответ:
Ооо! Подержите мой кофе, сейчас я вам кучу примеров расскажу и с Кафкой и с интеграциями. Но вы-то судя по вакансии управленца искали, а не того, кто сам микросервис напишет, вот я вам про другое и рассказывала.
Но я напишу, если надо)
Рассказала технические кейсы, скепсис ушел, собес прошла.
В следующий раз в другой компании я заранее спросила у рекрутера, почему отказали другим. И там оказалось наоборот: важен управленческий опыт.Хотя вакансия как раз была больше про технику 😃
На любой сеньорской позиции это может сыграть роль:
➡️ Кто-то ищет сеньора, который будет делать сложные задачи в заданном стеке и не спорить с архитектором.
➡️ Кто-то ищет того, кто будет сам проектировать, и акцент нужно делать именно на опыте принятия технических решений и проектирования микросервисов.
➡️ Кому-то нужен человек, который возьмет на себя релизы и тушение пожаров и нужны истории, как вы быстро и грамотно разрулили срочные баги на проде.
Да, эта информация не всегда есть у рекрутера, но если паре людей уже отказали за «недостаточную инициативность», то рекрутер вполне может этим поделиться. Он-то тоже хочет закрыть вакансию, а на хх фильтра по инициативности ещё не придумали 😃
Если вдруг рекрутер негативно воспримет ваши аккуратные вопросы про тех собес и других кандидатов (что вряд ли, но всякий случай), то можно ответить так:
Поделитесь, пожалуйста, что вы обычно спрашиваете у рекрутера?
Часто к общению с рекрутером/HR относятся формально: показать, что соответствуешь вакансии, узнать базовые моменты про оформление, ИТ-аккредитацию и всё.
Но рекрутера можно и нужно рассматривать как источник дополнительной информации, которая поможет пройти собес.
— Расскажите, пожалуйста, как устроен техсобес? Что обычно спрашивают: теорию, лайвкодинг, сисдиз? Будут ли на sql задачи? Может какие-то конкретные темы порекомендуете повторить?
В худшем случае рекрутер просто не ответит, но часто они охотно рассказывают.
Например, я наступила на такие грабли. Собесилась на позицию менеджера нескольких команд, аналогичную моей текущей. В вакансии были расписаны только менеджерские обязанности и требования соответственно про управленческий опыт🧑💼
Ок, в самопрезентации делаю акцент на этом. Вижу скепсис на лице нанимающего. Уточняю и получаю ответ:
— А реальный опыт руками что-то делать у вас есть? Приведите примеры, где вы занимались проектированием или сами писали что-то.
Ооо! Подержите мой кофе, сейчас я вам кучу примеров расскажу и с Кафкой и с интеграциями. Но вы-то судя по вакансии управленца искали, а не того, кто сам микросервис напишет, вот я вам про другое и рассказывала.
Но я напишу, если надо)
Рассказала технические кейсы, скепсис ушел, собес прошла.
В следующий раз в другой компании я заранее спросила у рекрутера, почему отказали другим. И там оказалось наоборот: важен управленческий опыт.Хотя вакансия как раз была больше про технику 😃
На любой сеньорской позиции это может сыграть роль:
Да, эта информация не всегда есть у рекрутера, но если паре людей уже отказали за «недостаточную инициативность», то рекрутер вполне может этим поделиться. Он-то тоже хочет закрыть вакансию, а на хх фильтра по инициативности ещё не придумали 😃
Если вдруг рекрутер негативно воспримет ваши аккуратные вопросы про тех собес и других кандидатов (что вряд ли, но всякий случай), то можно ответить так:
— Мне очень нравится ваша компания и вакансия, и по опыту я подхожу. Но весь опыт сложно успеть показать на собесе, поэтому хочу сориентироваться, что именно для вас важно и постараться показать свой опыт в этом.
Поделитесь, пожалуйста, что вы обычно спрашиваете у рекрутера?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заскуль питона (Data Science)
Господа-аналитики, ничего сложного, делаем 90% своей работы, все в порядке. А вот как работает все под капотом не было особо сильного понимания. Решил глянуть парочку источников...
Будем говорить в контексте работы с нераспределенными базами данных. К ним относятся: PostgreSQL, MySQL, Oracle, MS SQL.
Увидел формулировку ниже, решил покопать
Основная идея повышения скорости работы нераспределённой базы данных заключается в уменьшении количества операций чтения/записи с жёсткого диска
Но RAM выполняет функцию буфера, а данные хранятся на диске.
Предположим, у нас есть упрощенная табличка в нераспределенной базе данных
people со следующей структурой:CREATE TABLE people (
last_name varchar(32),
first_name varchar(32),
second_name varchar(32),
sex char(1),
birthday date
);
Допущение, что в среднем фамилия имя и отчество состоят из 7 RU символов,
а кодировка используется Unicode, тогда средняя строка займет на диске:
(7 * 2 + 1) * 3 + 2 * 1 + 4 = 51 байт
Один блок во многих учебных материалах идет в 4 кб (4096 байт)
=> В одном блоке содержится
4096 / 83 = 49 строк и 29 байт остатка
В таблице у нас 1000 записей, значит суммарно у нас будет блоков:
1000 / 49 ~ 20.4 блоков (округляем до 21)
Хотим сделать фильтрацию в SQL
select * from people where last_name IN ('Иванов', 'Петров', 'Сидоров'); Чтобы не читать лишние блоки и быстрее находить нужные записи можно пользоваться индексными структурами, про которые я хочу написать в последующих постах, поговорим о стоимости запросов и о том, где они хороши, а где нет. Все что нужно — это
А я то думал, что когда был в
думал, что все просто, но еще нужно много всего подучить
@zasql_python
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Базы данных & SQL
Уровни изоляции транзакций: практическая механика и сравнение PostgreSQL, MySQL, Oracle, SQL Server и DB2
"Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.
Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике."
Читать статью
"Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.
Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике."
Читать статью
Forwarded from Quant Valerian
Дочитал «Государь» Макиавелли
Честно говоря, книга очень слабо относится к управлению людьми. Но зато там много исторических отсылок и политота! А я такое люблю.
В общем-то книга это и не книга вовсе, а письмо к Лоренцо Медичи. Как отмечается в комментариях к книге (там люди читали и другие произведения Макиавелли и анализировали историю его жизни и публикаций), письмо суть прыжок веры, попытка получить призрачный шанс на то, что Италия сможет вновь объединиться под единой властью и выбраться из безпросветного хаоса и бедности. Сам Макиавелли не особо верит, что такое может случиться, но попытку не сделать он не мог.
Книга тоненькая, пересказывать не буду, сами прочитаете, если интересно.
Но вот, что я отметил.
Когда приходишь в завоеванную страну, чтобы в ней укрепиться, нужно стать защитником слабых и постараться ослабить сильных. Это и в социальных группах я часто наблюдал — лидрство захватывается именно так: приходит новый человек, собирает вокруг себя слабых (но не чмошников! а именно слабых из "нормисов") и по-тихоньку изолирует старого лидера, становясь на его место.
После смены лидера, поддержанной изнутри страны, народ быстро переходит от фазы эйфории к пониманию, что новый лидер ещё хуже, чем старый. Потому что новый вводит новые порядки и устои, обременяет захваченных новыми поборами и кормит с них войско. (Пришёл новый тимлид и стало только хуже)
Если никому не давать высказываться, то проиграешь, потому что упустишь лучшие решения, будешь слушать одну только лесть и пропустишь реальные проблемы. Если давать высказываться всем, то потеряешь уважение, как государь. Поэтому стоит выделить нескольких мудрых приближенных и предоставить им право высказывать всё, что они думают. Но высказываться только о том, о чем государь спрашивает и ни о чем более. Причем высказываться кулуарно, только на советах. Принимать решения нужно самому, выслушав все мнения. На советах нужно вести себя так, чтобы все знали, что чем смелее выскажут мнение, тем больше угодят государю. Однако вне советов никого слушать не надо. (Практикуем во всех командах поощрение высказывания мнения)
Ещё интересно, что государь в первую очередь военный. Должен демонстрировать доблесть. Его должны уважать воины. А для этого Макиавелли рекомендует регулярно упражняться в военном искусстве, даже в мирное время. (Что-то про тимлид должен кодить?)
Там ещё много удивительных кусочков, например, про избиение женщин ногами. Но оставлю это тизером.
Я ещё пытался накладывать на современных политиков, но выходило довольно посредственно.
Читали книгу? Что думаете про этику Макиавелли?
Честно говоря, книга очень слабо относится к управлению людьми. Но зато там много исторических отсылок и политота! А я такое люблю.
В общем-то книга это и не книга вовсе, а письмо к Лоренцо Медичи. Как отмечается в комментариях к книге (там люди читали и другие произведения Макиавелли и анализировали историю его жизни и публикаций), письмо суть прыжок веры, попытка получить призрачный шанс на то, что Италия сможет вновь объединиться под единой властью и выбраться из безпросветного хаоса и бедности. Сам Макиавелли не особо верит, что такое может случиться, но попытку не сделать он не мог.
Книга тоненькая, пересказывать не буду, сами прочитаете, если интересно.
Но вот, что я отметил.
Когда приходишь в завоеванную страну, чтобы в ней укрепиться, нужно стать защитником слабых и постараться ослабить сильных. Это и в социальных группах я часто наблюдал — лидрство захватывается именно так: приходит новый человек, собирает вокруг себя слабых (но не чмошников! а именно слабых из "нормисов") и по-тихоньку изолирует старого лидера, становясь на его место.
После смены лидера, поддержанной изнутри страны, народ быстро переходит от фазы эйфории к пониманию, что новый лидер ещё хуже, чем старый. Потому что новый вводит новые порядки и устои, обременяет захваченных новыми поборами и кормит с них войско. (Пришёл новый тимлид и стало только хуже)
Если никому не давать высказываться, то проиграешь, потому что упустишь лучшие решения, будешь слушать одну только лесть и пропустишь реальные проблемы. Если давать высказываться всем, то потеряешь уважение, как государь. Поэтому стоит выделить нескольких мудрых приближенных и предоставить им право высказывать всё, что они думают. Но высказываться только о том, о чем государь спрашивает и ни о чем более. Причем высказываться кулуарно, только на советах. Принимать решения нужно самому, выслушав все мнения. На советах нужно вести себя так, чтобы все знали, что чем смелее выскажут мнение, тем больше угодят государю. Однако вне советов никого слушать не надо. (Практикуем во всех командах поощрение высказывания мнения)
Ещё интересно, что государь в первую очередь военный. Должен демонстрировать доблесть. Его должны уважать воины. А для этого Макиавелли рекомендует регулярно упражняться в военном искусстве, даже в мирное время. (Что-то про тимлид должен кодить?)
Там ещё много удивительных кусочков, например, про избиение женщин ногами. Но оставлю это тизером.
Я ещё пытался накладывать на современных политиков, но выходило довольно посредственно.
Читали книгу? Что думаете про этику Макиавелли?
Forwarded from Yarick Abramov
GitHub - svc-develop-team/so-vits-svc: SoftVC VITS Singing Voice Conversion
https://github.com/svc-develop-team/so-vits-svc
https://github.com/svc-develop-team/so-vits-svc
GitHub
GitHub - svc-develop-team/so-vits-svc: SoftVC VITS Singing Voice Conversion
SoftVC VITS Singing Voice Conversion. Contribute to svc-develop-team/so-vits-svc development by creating an account on GitHub.
Forwarded from Андрей Созыкин (Andrey Sozykin)
YouTube
Шифрование в протоколе TLS | Компьютерные сети 2025 - 40
Лекция по шифрованию в протоколе Transport Layer Security.
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Начинаем рассматривать протокол TLS (Transport Level Security) и его применение для защиты данных в компьютерных сетях.
TLS устроен достаточно сложно, по нему будет несколько лекций. В первом видео подробно рассмотрим, как в TLS применяется шифрование для обеспечения приватности данных.
TLS использует гибридное шифрование:
- Симметричное шифрование для шифрования передаваемых данных, потому что оно работает быстро.
- Асимметричное шифрование для обмена ключами симметричного шифрования, которые нельзя передавать по сети в открытом виде.
Рассмотрим, как устроены алгоритмы асимметричного шифрования для обмена ключами RSA и Диффи-Хеллмана. В последней версии TLS 1.3 допускается использование только алгоритма Диффи-Хеллмана, а RSA считается небезопасным.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
TLS устроен достаточно сложно, по нему будет несколько лекций. В первом видео подробно рассмотрим, как в TLS применяется шифрование для обеспечения приватности данных.
TLS использует гибридное шифрование:
- Симметричное шифрование для шифрования передаваемых данных, потому что оно работает быстро.
- Асимметричное шифрование для обмена ключами симметричного шифрования, которые нельзя передавать по сети в открытом виде.
Рассмотрим, как устроены алгоритмы асимметричного шифрования для обмена ключами RSA и Диффи-Хеллмана. В последней версии TLS 1.3 допускается использование только алгоритма Диффи-Хеллмана, а RSA считается небезопасным.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.