Космическая лазерная связь становится нормой?

Компания Mbryonics получила почти 19 млн долларов от Европейского космического агентства (ЕКА) по программе HydRON (оптических и квантовых коммуникаций). Программа подразумевает тестирование межспутниковой лазерной связи и передачи данных в оптическом диапазоне между космическими аппаратами и наземными станциями. Почему лазер становится нормой в космосе?

Сразу скажем, что для космоса 19 млн долл. — сумма не очень большая, скорее, ЕКА стимулирует исследования в области, в которой отстаёт. Тесты лазерной связи проходят с 1990-х годов, но с 2020 года о её использовании заявили операторы многоспутниковых группировок США, Китая и России. В Европе же были только тесты в одиночных миссиях.

Планируется добиться скорости в 1 Тбит/с. Это больше, чем в тех же Starlink и Amazon LEO, но не стоит забывать, что для Mbryonics это единичный эксперимент, а у того же Starlink пусть и в 10 раз медленнее, но связываются 10 000 спутников. Так что не впечатляет.

Гораздо интереснее, что лазерная связь Mbryonics должна объединить спутники разных производителей на разных орбитах, а также обеспечить их связь с Землёй — фактически стать универсальным средством связи. В текущих многоспутниковых группировках она обычно используется для связи между спутниками. Хотя примеры связи «космический аппарат — Земля» были, тот же Orion в миссии «Артемида-2».

Потенциально лазерная связь имеет перед радиоволнами два преимущества. Максимально достижимая пропускная способность лазера на порядки выше, чем у радиоизлучения. Сейчас электроника стала достаточно компактной, чтобы реализовать это преимущество. Кроме того, оптический диапазон позволяет реализовать квантовое шифрование, которое делает доступными абсолютно защищённые линии связи на любых расстояниях. Законы квантовой физики гарантируют, что подключение к ней хакера будет замечено абонентами — важное свойство в современном мире, полном киберопасностей.

В результате применение лазерной связи вместо радио поднимет скорость передачи информации, поможет обеспечить защищённую связь — в целом логичное направление развития для ЕКА и ЕС в целом. Главное — реализовать, а то пока европейская система низкоорбитальной связи OneWeb не имеет лазерной межспутниковой связи и заметно проигрывает по характеристикам сети Starlink.

Долгое время разделение было почти кастовым: одни пишут код и строят модели, другие ведут переговоры и рассказывают истории. Каждый лагерь немного презирал другой. Это было удобно, понятно и — как выясняется — безнадёжно устарело.

Генеративный ИИ сломал эту систему не потому, что «заберёт работу». Он сломал её потому, что изменил саму единицу ценности специалиста.

Что говорят данные

PwC и MIT проанализировали требования к позициям, связанным с Gen AI, и получили неудобный результат. Роли с ИИ требуют на 36,7% больше когнитивных навыков, чем аналогичные позиции без него. Но одновременно устойчиво растёт спрос на социальные компетенции: эмпатию, лидерство, суждение в условиях неопределённости.

Логика железная: машина забирает рутину, обработку данных, генерацию контента. Человеку остаётся то, с чем LLM справляется плохо — интерпретация, этика, контекст и доверие. А доверие, к слову, до сих пор не токенизируется.

π-shaped как новый стандарт найма

McKinsey и Google уже несколько лет оперируют концепцией π-shaped специалиста: два вертикальных столба глубокой экспертизы плюс горизонтальная гибкость между ними.

В контексте AI это выглядит так:

• Столб 1 — техническая AI-грамотность: понимание архитектуры языковых моделей, промпт-инжиниринг, работа с API и осознание ограничений систем

• Столб 2 — человеческий интеллект: эмоциональный, социальный, этический

• Перекладина — способность переключаться между этими режимами в рамках одной задачи

Продакт, который понимает разницу между RAG и fine-tuning и при этом умеет провести глубинное интервью с пользователем — это уже не «редкий зверь», это просто новый минимальный стандарт для сильных команд.

Как это развивать — без воды

• AI-грамотность — не обязательно писать код, но необходимо понимать, как работают языковые модели, где они галлюцинируют и как правильно декомпозировать задачу для промпта

• Практика суждения — берите кросс-функциональные проекты, где нет единственно правильного ответа. Именно там тренируется то, что модель сымитировать не может

• Осознанная коммуникация — это не «навык презентаций». Это умение слышать, адаптировать месседж под аудиторию и строить доверие. Прокачивается через фасилитацию и наставничество, а не через курсы ораторского мастерства

• Рефлексия — те, кто регулярно разбирает собственные решения и открыт к критике, накапливают опыт, который не дистиллируется в веса модели

Почему это не очередной buzzword

Автоматизация не уничтожает рабочие места — она реструктурирует их. Исчезают позиции, где человек выполнял функцию дешёвого процессора. Появляются роли, где нужен человек с AI-усиленным интеллектом — и именно они получат премию за гибридность в зарплате, карьере и реальном влиянии на результат.

Вопрос уже не «технарь вы или гуманитарий». Вопрос в том, как быстро вы готовы перестать считать это противоречием.

Честно говоря, когда ты создаешь продукт небольшими ресурсами, небольшими сбережениями и увлеченной командой таких же как и ты мечтателей, то каждое изменение в процессе становится событием. Это не про сорвать инвестиции или получить грант. Это довольно трушно. И иногда жестко — когда приходится отказывать себе в каких-то вещах.

Я со своими друзьями создал гаджет с забавным пиксельным экраном, который крепится на окно снаружи. В каком-то смысле — эволюция бабушкиного градусника за окном. Нам пришлось наделать кучу ошибок. Я их называю тем самым — Fking fail. Каждый раз я думал, что вот эта ошибка точно последняя. Что теперь мы стали опытнее и уж точно знаем, как всё решить без больших денег и отставания во времени.

(спойлер: нет)

На этом видео появляется деталь для нашего будущего датчика качества воздуха Atmy.

Это всего лишь защитное стекло. Но для меня это невероятно важное событие, из-за которого последние месяцы я плохо спал.

Две фабрики пытались отлить это стекло. И каждый раз — Fking fail: — проблемы с формой — не тот оттенок — спайки на поверхности Мы меняли модель. Дорабатывали пресс-формы. Ждали новые образцы. И каждый раз одно и то же: получаешь посылку с образцом → открываешь → смотришь → снова не то. В какой-то момент одна фабрика просто сказала, что больше ничем помочь не сможет. Мы уже производили первую версию датчика — NeboAir. И там защитное стекло вырезалось из листового материала. Лазер по краям оставлял неровную, волнообразную поверхность. Наверное, стоило так и оставить. Это уже отработанная схема. И, честно, ни один пользователь не пожаловался на эту еле заметную особенность. Но я хотел сделать лучше. И это желание стоило мне потерянных 5000$ и новых затрат на разработку. Для крошечного стартапа это был самый настоящий Fking fail. Но он того стоил.

Сейчас, после всех согласований, последняя фабрика в Китае смогла завершить проект и запустить стекло в производство. Наш продукт стал ещё чуточку лучше.

Совершайте ошибки. И знайте — стартапы это весело🐙

Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.

📅 Расписание по дням

_{Понедельник, 27 апреля}

• 20:00 — «Рисуем в формате онлайн модель процесса BPMN в Camunda Modeler»

• 20:00 — «Настройка кластера Elasticsearch»

_{Вторник, 28 апреля}

• 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»

• 20:00 — «Архитектура ИИ врагов в играх на Unity»

• 20:00 — «Первый нагрузочный тест в Apache JMeter»

• 20:00 — «Архитектура тестового фреймворка: от хаоса к стабильности»

• 20:00 — «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»

• 20:00 — «Фоновые задачи в Django: работа с Celery»

• 20:00 — «Как работают современные модели компьютерного зрения „из коробки“ на базе популярных библиотек и фреймворков (Hugging Face, OpenCV, YOLO, Roboflow)»

• 20:00 — «Почему только 5% компаний получили реальную выгоду от ИИ в 2025 году?»

_{Среда, 29 апреля}

• 20:00 — «Деревья решений для задач классификации и регрессии»

• 20:00 — «Свой язык на PHP за 60 минут»

• 20:00 — «Трекинг с подвижной камеры: алгоритмы и механика компьютерного зрения на роботах для индустриальных задач»

• 20:00 — «Разрешите себе карьеру технического директора»

• 20:00 — «Качество C#‑кода: от модульных тестов к системному подходу»

• 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»

_{Четверг, 30 апреля}

• 19:00 — «МОК‑интервью на позицию Руководитель Проектов»

• 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»

• 20:00 — «Yahoo Finance и не только — работа с российскими торговыми площадкам»

• 20:00 — «Поиск в базе знаний: где векторы ошибаются, а графы помогают»

• 20:00 — «Как управлять тимлидами?»

• 20:00 — «Битрикс24 + MAX: разработка чат‑ботов и автоматизация коммуникаций» 

• 20:00 — «Планируем внедрение DevSecOps — что следует учесть?»

Мы перечислили 20 открытых вебинаров на эту неделю. Если вы не нашли в расписании тему, которая нужна именно вам, — загляните в полный календарь

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.8. – "Формирование и поддержание в актуальном состоянии правил кодирования". На YouTube. Слайды.

Цели восьмого процесса по ГОСТ Р 56939—2024:

Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Эта подборка статей поможет подготовиться к собеседованиям на разные позиции. Вы лучше поймете, как проходят собеседования, какие вопросы могут задать и как грамотно на них отвечать. В материалах собраны примеры задач, технических и общих вопросов, а также советы от наших экспертов.

Фронтенд-разработчик: вопросы на собеседовании и как подготовиться. Чеклист тем, которые стоит повторить: HTML, CSS, JavaScript, фреймворки, библиотеки и инструменты. Также делимся примерами практических заданий и общих вопросов для оценки софтскилов.

Системный администратор: вопросы на собеседовании и как подготовиться. Короткая статья, которая поможет собраться с мыслями и почувствовать себя увереннее. Делимся примерами общих и технических вопросов, а также практических задач. Советуем, как лучше отвечать, чтобы произвести хорошее впечатление.

Java-разработчик: вопросы на собеседовании и как подготовиться. Отвечаем на самые популярные вопросы на собеседованиях и рассказываем, как качественно подготовиться и что повторить. Можно использовать как шпаргалку, чтобы быстро освежить материал перед интервью.

Python-разработчик: вопросы на собеседовании и как подготовиться. Рассказываем, какие вопросы могут задать по базовым и продвинутым темам, а также делимся хорошими вариантами ответов. Также объясняем, как избежать ошибок при подготовке и на самом интервью.

Когда я пришёл в WB, передо мной встала задача подтянуть управленческие навыки сразу нескольких руководителей разработки. Я начал работать с каждым по отдельности в рамках встреч 1-на-1, но хотелось ускорить процесс.

И тут я вспомнил, как папа учил меня мыть картошку. Достаточно пересыпать её в ведро, залить водой, взять деревянную палку и хорошенько пошуровать. Оказалось, картофелины моют друг друга гораздо быстрее, чем если отмывать каждую по отдельности.

Я выбрал нескольких руководителей и попросил их поделиться опытом с коллегами, подготовив небольшие презентации на разные темы: как нанимать людей, управлять проектами, развивать команду и т.д.

В итоге получилось убить сразу нескольких зайцев:

• При подготовке к докладу выступающий систематизировал свои знания на тему и сам начинал в ней лучше разбираться.

• Слушатели воспринимали слова коллеги, которого они давно знают, с бóльшим доверием, чем если б они исходили от меня, нового руководителя, который ещё не успел завоевать авторитет.

• Тимлиды поняли, что можно обсуждать управленческие навыки с коллегами, интересоваться чужим опытом и делиться своим. Не стыдно что-то не уметь, стыдно не учиться.

Принцип ведра картошки сработал.

Полный цикл математического образования Китая — от начальной школы (1–6 классы) до вузовских курсов: высшей математики, линейной алгебры, дискретной математики и теории вероятностей. Также доступны материалы по системе «5–4» (пятилетняя начальная и четырехлетняя средняя школа) и подборка экзаменационных задач с ответами.

Из‑за ограничений GitHub на размер файла крупные PDF разбиты на части (например, file.pdf.1 и file.pdf.2). Для их объединения в репозитории предусмотрена утилита mergePDFs‑windows‑amd64.exe, которая автоматически собирает исходный документ.

Объем скачанного репозитория > 40 Гб

$repoOwner = "TapXWorld"
$repoName = "ChinaTextbook"
$url = "https://api.github.com/repos/$repoOwner/$repoName"
$response = Invoke-RestMethod -Uri $url
$sizeInMB = $response.size / 1024
Write-Output "Размер репозитория: $sizeInMB MB"

# Размер репозитория: 42523.3662109375 MB
git count-objects -vH
count: 0
size: 0 bytes
in-pack: 4399
packs: 1
size-pack: 41.52 GiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes

# curl -s https://api.github.com/repos/TapXWorld/ChinaTextbook | jq '.size' - 43543927
# больше 40 Гб занимает pack-3a5a6dbd895b2f8703925664f6ff7e4aa62d04c3.pack

Прошлый пост про Whisper + pyannote на AMD читают, но молчат) Ладно, продолжу.

У меня две свободные машины. На 4090 живёт DeepSeek-R1-32B с LoRA-адаптерами, весь VRAM его. На AMD RX 7900 XTX крутятся Whisper + pyannote — занимают ~5 GB из 24. Свободно 19 — решил добавить Qwen2.5-VL-7B для чтения изображений: фото документов, визитки, скриншоты. В bf16 модель весит ~14 GB, должна влезть.

Поставил, запустил оба systemd-сервиса — система зависла намертво. Две модели грузятся параллельно, каждая маппит safetensors в оперативку перед VRAM — а RAM всего 15 GB. OOM killer, рестарт, снова OOM, цикл. Грузился через GRUB в текстовый режим (параметр 3, но без nomodeset — иначе amdgpu не поднимется). Отключил GUI — framebuffer ещё 1-2 GB VRAM жрал. Swap до 16 GB, последовательный запуск. Заработало.

Отправил фото страницы A4 — инструкция кондиционера, русский, два столбца. Через 398 секунд получил одну строку и бесконечный loop: "Постановление Правительства!!!!!!"!!!!!!!#!!!!!!!$...". Шесть минут на мусор. На коротких описаниях картинок модель работала нормально — 35 секунд, осмысленный текст. Но OCR документов — полный провал.

Первая мысль — bottleneck в железе. У меня опыт с CUDA→HIP конвертером, 500+ проектов, уже приготовился конвертировать flash-attention под RDNA3. Но сначала бенчмарки: attention — работает (AOTriton 1.9ms), FFN — 1.73ms, text-only генерация — 6 tok/s. Железо в порядке, flash-attention конвертировать не нужно.

Виновник — repetition_penalty=1.15. Добавил для борьбы с loop’ами, стандартная практика. На ROCm этот параметр даёт 2.3x замедление. На NVIDIA дешёвый, на AMD дорогой. Нигде не документировано. Убрал, добавил early-stop через StoppingCriteria — каждые 24 токена проверяю хвост, если loop — прерываю. Итог: 398с → 13с.

Но из целой страницы модель вытащила полтора предложения — 114 символов из 2000+. Семёрка теряет фокус на длинных документах. Сделал ресёрч — для Qwen2.5-VL критично разрешение и количество vision-токенов. Пошёл путём препроцессинга: OpenCV pipeline перед моделью (выравнивание, контраст, резкость), увеличил max_pixels в processor. Главное — tiled OCR: режу фото на 3 полосы, каждую отдельно, склеиваю. Single-pass: 114 символов. Tiled: 3077 символов, 85% покрытия. Не идеал — есть повторы на стыках, двухколонные путают — но направление правильное.

Кстати, для общения с моделями использую SimpleX CLI. На сервере Python-bridge слушает WebSocket, маршрутизирует: голосовое → Whisper, фото → Qwen-VL. С телефона отправил — через минуту ответ в чате. Если интересно — расскажу подробнее.

Что важно, если ставите vision-модель на AMD: OOM при параллельном старте - swap + задержка между сервисами. GUI отключить если VRAM впритык. local_files_only=True при загрузке модели. И repetition_penalty на ROCm — заменить на early-stop, серьёзно.

Стек: AMD RX 7900 XTX 24GB, PyTorch 2.5.1+ROCm 6.2, Qwen2.5-VL-7B bf16, Whisper + pyannote — три модели на одной карте, Ubuntu 24.04 без GUI.

Прочитал книжку «API Design Patterns» от бывшего разработчика Google — JJ Geewax, и это, на удивление, полностью ненужная книжка.

По названию вы можете подумать, что это книга поможет вам проектировать какое-то публичное API либо как-то выстроить эффективное взаимодействие для внутреннего API, но фактически это максимально обзорная книжка, где намешано куча всего — начиная от REST и заканчивая проектированием связей в базе данных и политикой ретраев.

Особенно доставляет, что на большинство вопросов автор приводит несколько подходов, но не даёт никакого обоснования, где и когда нужно применять тот или иной подход. «Просто есть несколько вариантов — выбирай мудро» (с).

По самому предложенному варианту API тоже есть вопросы, ибо за свою 12-летнюю карьеру и знакомство с множеством реализаций API я ни разу не видел того, что предложил автор. Возможно, это внутренняя штука от Google, которая не стала широко используемой, но в Google её используют.

Ну и самое главное — в книге нет никакой целостности. Словно автор просто брал какую-то тему, писал про неё 6–8 страничек, потом брал новую тему и снова писал 6–8 страничек. И какой-то связи между этими главами нет.

В общем, не нужно тратить время на эту книжку. Книжка из моего предыдущего поста была в разы лучше и структурированнее.

Наконец-то спустя почти год и два месяца моя CMS-ка для ведения блога получила более менее внятный релиз-кандидат, в котором ошибок осталось не так много, и в принципе система уже легко ставится на хостинг и управляется.

Впереди - куча оптимизации, например вынесение всех форм шаблона админки в контроллеры, и последующий их рендеринг через render_form(). Данные контроллеров в json и так далее.

Но - текущая версия движка с последующими обновлениями уже не сломается, как это было в первых релизных версиях.

Ну и самое главное - официальный сайт. Как оказалось - это одна из тех задач, которая весьма объемна и кропотлива - это и документация, и каталог дополнений с API для разработчиков и еще много-много чего.

Приглашаю к тестированию: https://github.com/pechoradev/BloggyCms

Также буду рад видеть новых контрибьюторов CMS.

Большая часть проблем с крипто-переводами возникает не из-за “сложности блокчейна”, а из-за слишком бытовых ошибок.

Не ту сеть выбрали. Скопировали адрес, но не сверили хвост. Забыли про memo/tag. Отправили “впритык”, а после комиссии сумма стала ниже минимального порога. Итог всегда один: деньги вроде бы отправлены, но дальше начинается нервный квест. Парадокс в том, что большинство таких ошибок можно поймать за 30–60 секунд до отправки.

Ниже короткий anti-fail чеклист, который реально стоит прогонять перед любым крипто-переводом, особенно если сервис новый, сумма чувствительная или вы работаете в спешке.

Первое: сеть.

USDT в ERC-20, TRC-20, BEP-20 и других сетях визуально выглядит как “тот же USDT”, но на практике это разные маршруты. Ошибка здесь одна из самых дорогих и самых частых.

Второе: адрес.

Недостаточно просто вставить адрес в поле. Стоит хотя бы сверить первые и последние символы. Ошибки буфера, подмена адреса вредоносным ПО и банальная спешка - классика.

Третье: связка “актив + сеть”.

Многие проверяют только монету или только сеть. Но ошибка часто возникает именно в комбинации: актив может быть правильный, а маршрут нет.

Четвёртое: комиссия и итоговая сумма.

Если перевод идёт “впритык”, комиссия может сделать сумму ниже минимального порога зачисления. На экране кажется, что всё ок, а по факту деньги зависают или требуют ручной разбор.

Пятое: минимальная сумма зачисления.

Во многих сервисах маленький перевод технически доходит в сеть, но не зачисляется автоматически. Пользователь видит успешную транзакцию и не понимает, почему баланс не пополнился.

Шестое: memo, tag или дополнительный идентификатор.

Для некоторых активов одного адреса недостаточно. Если пропустить это поле, перевод может пройти в сеть, но не привязаться к аккаунту без ручной поддержки.

Седьмое: тестовый перевод.

Самый скучный совет, но самый дешёвый. Если сервис новый, сеть непривычная или сумма ощутимая, то сначала лучше отправить небольшую часть, а уже потом основную сумму.

Если упростить всё до одной мысли, то крипто-перевод это не место, где стоит доверять автопилоту. Одна минута проверки почти всегда дешевле, чем потом разбираться, куда “ушли” деньги и почему они не дошли туда, куда должны были.

Если вы работаете с машинным обучением или исследовательскими задачами, arXiv, скорее всего, — ваш основной источник свежих идей.

Но далеко не всегда удобно читать оригинал на английском: устали, хотите быстро пробежаться по статье или просто не готовы сейчас разбираться в длинном PDF.

В этом посте — два практичных способа читать статьи с arXiv в HTML‑формате прямо в браузере и сразу переводить их на русский с помощью встроенного перевода. Никаких LLM, сторонних ботов и скачивания PDF.

Зачем вообще HTML, если есть PDF

Классический сценарий работы с arXiv выглядит так: вы открываете страницу статьи, скачиваете PDF и читаете его в отдельной программе или через встроенный viewer браузера.

У такого подхода есть несколько минусов:

• Неудобно переводить: нужно копировать текст или использовать отдельные инструменты.

• Плохо искать по странице: текст может быть нераспознанным или разбитым.

• Тяжелее читать на маленьких экранах, особенно на ноутбуках и планшетах.

HTML‑версия решает эти проблемы: текст становится «живым», браузер может его переводить, а навигация и поиск по странице работают привычным образом.

Способ 1. Официальный HTML (experimental)

У части статей на arXiv есть встроенная HTML‑версия.Если она включена, справа на странице вы увидите кнопку «HTML (experimental)».

Что это даёт:

• статья открывается как полноценная HTML‑страница;

• формулы остаются корректными;

• можно использовать встроенный перевод в браузере.

Ограничения:

• HTML‑версии есть не у всех препринтов.

• Иногда верстка «плывёт», особенно в сложных таблицах.

Способ 2. ar5iv (если HTML нет)

Если кнопки HTML (experimental) нет, можно воспользоваться сторонним сервисом ar5iv из экосистемы arXiv Labs. Он автоматически конвертирует TeX‑исходники статей в HTML.

Идея простая: вы берете обычный URL arXiv и меняете в домене букву x на 5.

Пример:

• Было: https://arxiv.org/abs/1706.03762

• Стало: https://ar5iv.labs.arxiv.org/html/1706.03762

Такой простой приём заметно снижает «порог входа» в чтение статей и экономит время, особенно если вы регулярно мониторите arXiv.

Возникла тут недавно необходимость использования двух приборов САУ-М7Е, электродов было всего 4, необходимо было объединить общий вывод приборов между собой. Но проблема была в том, что между общим входом двух приборов присутствовал потенциал, номиналом порядка 40 В, и протеканием тока примерно в 600 мА.. После чего, один из приборов, благополучно сгорел..

Проблему необходимо было решать. И на ум пришла схема с использованием балластных сопротивлений (для ограничения протекания такого "большого тока"), общим номиналом порядка 1.2 кОм.. Схема представлена ниже:

p.s.. вдруг кому пригодится, для объединения двух и более приборов САУ, от фирмы ОВЕН..

Стоит отметить, сопротивления в 10W рассеиваемой мощности, применены не просто так. Согласно формуле P = I^2 * R * 2, - этого более чем достаточно..

Спасибо!

Базовая версия: https://github.com/fmhy/FMHYFilterlist#howtouse-basic.

Продвинутый вариант: https://github.com/fmhy/FMHYFilterlist#howtouse-plus.

Полный список угроз и базовый репозиторий: https://github.com/fmhy/FMHYFilterlist.

Такой вариант хорошо подходит, если нужно:

• показать скрипт на чужом компьютере;

• поработать на машине без прав администратора;

• запускать Python в ограниченной среде;

• держать рядом интерпретатор, проект и зависимости в одном месте.

На корпоративных ПК всё зависит от политики безопасности. Если запуск с USB, .exe или PowerShell ограничен, портативная сборка тоже может не стартовать.

Что нужно

Минимальный набор простой:

• USB-накопитель;

• Windows x64;

• доступ в интернет, если планируете ставить дополнительные пакеты.

Скачиваем Python

Идём на официальную страницу загрузок Python и берём Windows embeddable package (64-bit) для нужной версии, например, python-3.14.4-embed-amd64.zip.
После распаковки вы получите что-то вроде этого:

F:\
└── python3.14\
    ├── python.exe
    ├── python314.dll
    ├── python314._pth
    ├── python314.zip
    └── ...

На этом этапе интерпретатор уже можно запускать прямо с флешки.

Что делает _pth

Файл python314._pth управляет тем, какие пути Python видит при запуске. По умолчанию embeddable package изолирован от системного окружения, реестра и установленных пакетов.

Если вам нужно подключить локальные библиотеки, можно прописать пути вручную:

python314.zip
.
Lib
Lib\site-packages
import site

Строка import site нужна, чтобы Python начал использовать site-механику и подхватывать дополнительные каталоги.

Как добавить pip

У embeddable package pip обычно не идёт «из коробки» как в обычной установке.
Его можно добавить вручную через официальный bootstrap-скрипт get-pip.py.

Сценарий такой:

1. Скачайте get-pip.py.

2. Положите его рядом с python.exe.

3. Запустите:

PS F:\> cd ./python3.14
PS F:\python3.14> ./python get-pip.py

После этого проверьте:

./python -m pip --version
# Выведет версию pip (например, pip 26.0.1).

Ставим пакеты

Когда pip уже доступен, можно ставить нужные библиотеки:

PS F:\python3.14> ./python -m pip install numpy pandas matplotlib seaborn requests

Или сразу из requirements.txt:

PS F:\python3.14> ./python -m pip install -r requirements.txt

Запускаем проект

Чтобы не помнить длинные пути, удобно сделать run.bat в корне флешки:

@echo off
cd /d %~dp0
set PYTHON_HOME=%~dp0python3.14
set PATH=%PYTHON_HOME%;%PATH%

%PYTHON_HOME%\python.exe my_project\main.py
pause

Плюс такого подхода в том, что он не привязан к букве диска. Сегодня флешка может быть F:, а завтра D: — батник всё равно найдёт себя сам.

Типичная структура

Обычно папка на флешке выглядит так:

F:\
├── python3.14\
│   ├── python.exe
│   ├── python314.dll
│   ├── python314._pth
│   ├── python314.zip
│   └── Lib\site-packages\
├── my_project\
│   ├── main.py
│   └── requirements.txt
├── run.bat