7.Закрой руфус и подключи мышь в синий порт 3.0, а клаву в чёрный 2.0
8.Выключи пк и включи
9.Выбери запуск с флешки.
10.Выбери пункт первый
11.Тести
Если не сработало на пк то тести на Virtual BOX. Если захочешь установить на диск смотри что я делал на видео. Если нашёл баги пиши в коменты. Смотри чтобы работало надо чтобы была и клавиатура и мышь. Ставь лайк и подпишись чтобы поддержать меня!
А не буду трындеть про неотключаемую телеметрию (сколько не пробовал - победить на 100% не смог, кстати Canpnical, который выпускает популярные дистры *buntu так же пошёл по ентому пути, но хотя бы отключить можно). Да, мелкософт запросто сливает не только инфу об операционке и установленных прогах, но так же снифает как клаву, так и мышку. Учитывая законодательство США, они всё енто сливают нашим “зарубежным коллегам” из АНБ. Это происходит со всеми программными конторами США, гугель пытался бодаться, но слил, так что и Ваши поисковые запросы через гугель так же сливаются в АНБ.
Вроде дно уже пробито, но снизу снова постучались. Винда-11 самостоятельно удаляет оригинальные драйвера дискретных карт с компа. Всё что нужно сделать - не играть, т.е. не загружать дискретную видеокарту в течение недели-двух. Логика проста, если дискретка не задействуется, а работа идёт на встройке, то ради экономии места и энергосбережения можно удалять дрова дискретки и подменить их на “стандартный видеодрайвер Microsoft“.
Вот так вот, решил через неделю-две погамать в “танчики” на выходных, а тебе кукиш с маслом. Всё енто происходит во время обнов (которые я даже в 10ке полностью отрубить не смог).
Так что знайте - как только установили винду на комп, то вы его уже не контроллируете, это он контроллирует Вас.
Источников море, но, что бы не быть голословным, приведу хотя бы один.
Все началось с рабочей задачи по реализации весьма специфичной web-панели мониторинга и управления различным оборудованием, в которой нужно было получать данные и отправлять команды по разнообразным сценариям (периодический опрос, подписка на websocket-события, https-запросы и т.д.), а также выводить состояние и графики в реальном времени, динамически комбинируя различные источники данных в разных виджетах.
Кроме того, у панели было предусмотрено несколько настраиваемых режимов работы, которые переключались по запросу пользователя, что требовало массового управления маршрутами потоков данных внутри системы.
В первой итерации с использованием RxJS получилось много неструктурированного и сложно поддерживаемого кода, так как архитектура на RxJS вынуждала императивно описывать перестроение топологии при изменении правил маршрутизации «на лету». В нашем специфичном кейсе с динамическими виджетами это приводило к сайд-эффектам и сложностям в отладке. Кроме того, местами размывалась строгая типизация и мы лишались compile-time гарантий. Так появилась идея разработать собственное решение на основе альтернативной концепции — модели графа потоков данных.
В результате получившаяся модель продемонстрировала предсказуемое поведение и низкую связность компонентов, а кодовая база сократилась на ~30% и приобрела более декларативный вид. Убедившись в эффективности решения, мы решили оформить его в виде отдельной библиотеки с открытым исходным кодом — Transferum.
И что, получилась просто еще одна реактивная библиотека?
Не совсем. Классические FRP-библиотеки (RxJS, Bacon, Most) построены вокруг единственного примитива (Observable). Transferum же основан на композиции различных типов узлов с явно определенным поведением.
Каждый узел в графе потоков распространения данных явно декларирует свои способности: может ли он принимать данные через push, отдавать через pull, распространять полученный сигнал подписчикам, опрашивать источник, фильтровать, блокировать поток и т.д.
Объявленные узлом возможности являются одновременно флагами для использования в runtime и compile-time гарантиями наличия соответствующих методов, определяющих его поведение.
Ключевая идея: поведение системы описывается как композиция независимых возможностей, которые одновременно определяют тип, реализацию и правила взаимодействия.
Transferum предоставляет четыре слоя абстракции:
Трансферы — узлы графа (каналы, поллеры, мапперы, буферы, разветвители и концентраторы, реализации debounce, throttle, switchMap и т.д.).
Мосты — ребра графа — управляемые вентили между узлами с динамической маршрутизацией и гейтингом.
Операторы — stateless-трансформаторы и фильтры данных (используются трансферами, отвечающими за конвертацию данных).
Билдеры — fluent-конструкторы композитных трансферов из цепочек трансферов-примитивов.
Концептуальная и архитектурная основа — capability flags system. Каждый трансфер реализует CommunicationContractInterface — набор булевых флагов, определяющих его возможности.
Флаги isPushable, isPullable, isSubscribable, isGate и другие — это не просто свойства объекта. Это метаданные, которые:
Определяют TypeScript-интерфейс трансфера на этапе компиляции.
Управляют стратегией связывания с другими трансферами в рантайме (с помощью функции linkTransfers()).
Обеспечивают совместимость в билдерах без приведений типов.
Один набор флагов — три потребителя. Это единый источник истины для всей системы.
Когда флаг равен true, соответствующий метод входит в TypeScript-интерфейс трансфера. Это позволяет предоставлять трансфер пользователю вот так:
Transfer
// гомогенный трансфер: T -> [ Transfer ] -> T
Или вот так:
Transfer
// гетерогенный трансфер: TInput -> [ Transfer ] -> TOutput
Именно в таком формате типов фабрики в библиотеке возвращают трансферы. Например:
const pushChannel: Transfer;
const converter: Transfer;
// содержат методы push(), subscribe()
const manualBuffer: Transfer;
// содержит методы push(), pull(), trigger()
// trigger() в данном случае нужен, чтобы сделать запушенное значение
// доступным для чтения через pull()
const pollingProxy: Transfer
// содержит методы pull(), subscribe(), trigger(), activate(), deactivate(), toggle()
// может быть связан с pullable-источником благодаря поддержке поллинга
Эта «магия» работает в compile-time благодаря несколько замысловатой системе вычислимых типов:
Трансфер определяет своё поведение (push, pull, subscribe и др.), но никогда не ссылается и не проверяет класс другого трансфера. Он не знает, что является upstream или downstream — лишь выполняет свой контракт. Пользователь может создать свой трансфер, объявить и реализовать его возможности — и он органично и бесшовно впишется в экосистему.
2. Мосты не знают конкретных реализаций
Мост инспектирует capability flags, а не имена классов. Нет цепочки instanceof, нет переключения по имени класса. Любой output-трансфер может быть соединен с любым input-трансфером — при условии совместимости их флагов, о чем мы поговорим чуть ниже. Это применимо и к тем узлам, которые еще не существуют и будут созданы пользователем.
3. Значение undefined никогда не распространяется
В Transferum undefined означает «нет данных», а не «пустое значение». Оно подавляется на уровне внутренней реализации менеджера подписок — подписчики никогда не уведомляются с undefined. При этом для явных маркеров пустых значений можно использовать null. Мы сознательно пошли на этот компромисс, чтобы избежать runtime-оверхеда и сохранить нативную скорость работы на плотных потоках данных.
Связывание трансферов
Функция linkTransfers(lhs, rhs) соединяет output-трансфер (lhs) с input-трансфером (rhs) с автоматическим выбором стратегии связывания на основе возможностей этих трансферов:
Protocol-oriented design: механизм не спрашивает «какой это класс?» — он выясняет, какие у него есть возможности. Любая пара трансферов с совместимыми возможностями является linkable. Добавление нового класса трансфера требует только объявления его флагов и реализации соответствующих методов — как связать его с другим трансфером, связующий алгоритм разберется сам.
Синхронные и асинхронные трансферы сосуществуют и могут быть связаны между собой. linkTransfers() предпочитает sync-связывание, когда это возможно, а async-стратегии применяет только когда sync неприменим. Нет отдельного «асинхронного мира».
Поддержка backpressure
Ряд асинхронных трансферов (AsyncSinkTransfer, AsyncWriteTransfer, AsyncConvertTransfer, AsyncConditionTransfer) поддерживают необязательные поля в конфигурации: maxConcurrency, bufferSize и onBufferOverflow — для ограничения параллельных async-операций, очереди избыточных данных и graceful-обработки переполнения. По умолчанию — неограниченная обработка, без буферизации.
Локальная обработка ошибок
Transferum использует единую модель обработки ошибок для всех трансферов. Каждый трансфер, который может столкнуться с runtime-ошибкой, принимает опциональный onError-хэндлер в своей конфигурации.
А теперь — к примерам использования
Вот так можно просто и декларативно описать опрос и агрегирование данных из нескольких источников:
А вот как можно организовать динамический роутинг:
import {
createPushStoredChannelTransfer,
createBridgeMultiSelector,
createBridgeSelector,
createPassBridge,
} from 'transferum';
// Вариант 1. Выбор одного реципиента
const commandRouter = createBridgeSelector({
bridges: {
light: createPassBridge({ source: commandChannel, target: lightController, activated: false }),
thermostat: createPassBridge({ source: commandChannel, target: thermostatController, activated: false }),
lock: createPassBridge({ source: commandChannel, target: lockController, activated: false }),
},
initialKey: 'thermostat', // выбор по умолчанию
activated: true,
owned: true,
});
commandRouter.select('lock'); // выберем другой вариант
// Вариант 2. Выбор нескольких реципиентов
const loggersRouter = createBridgeMultiSelector({
bridges: {
prometheus: createPassBridge({ source: metricsChannel, target: prometheusWriter, activated: false }),
elk: createPassBridge({ source: metricsChannel, target: elkWriter, activated: false }),
sentry: createPassBridge({ source: metricsChannel, target: sentryWriter, activated: false }),
},
initialKeys: ['prometheus', 'elk'], // будут активированы по умолчанию
activated: true,
owned: true,
});
loggersRouter.check('elk'); // теперь выбраны все три
loggersRouter.uncheck('prometheus'); // выбраны elk, sentry
loggersRouter.select(['prometheus', 'sentry']); // выбраны prometheus, sentry
А вот пример c организацией игровой механики:
import {
createDebounceTransfer,
createConvertTransfer,
createMapOperator,
createBridgeSelector,
createPassBridge,
linkTransfers,
} from 'transferum';
// Источник: debounce нажатий клавиш (16ms ~ 1 кадр при 60 FPS)
const rawInputSource = createDebounceTransfer({ delay: 16 });
// Конвертер: KeyboardEvent -> код клавиши
const inputConverter = createConvertTransfer({
operator: createMapOperator((event) => event.code),
});
// Целевые системы-потребители пользовательских событий
const carSystem = { push: (cmd: string) => console.log(🚗 Car executing: ${cmd}) };
const planeSystem = { push: (cmd: string) => console.log(✈️ Plane executing: ${cmd}) };
const menuSystem = { push: (cmd: string) => console.log(📋 Menu processing: ${cmd}) };
// Роутер: динамическое переключение между игровыми контекстами
const gameplayRouter = createBridgeSelector({
bridges: {
driving: createPassBridge({ source: inputConverter, target: carSystem }),
flying: createPassBridge({ source: inputConverter, target: planeSystem }),
ui: createPassBridge({ source: inputConverter, target: menuSystem }),
},
initialKey: 'driving', // игрок начинает в машине
activated: true,
});
// Связывание источника с конвертером с автовыбором стратегии
linkTransfers(rawInputSource, inputConverter);
// Демонстрация:
// Игрок в машине нажимает "W"
rawInputSource.push(new KeyboardEvent('keydown', { code: 'KeyW' }));
// Через 16ms: 🚗 Car: KeyW
// ==================
// Переключаемся на самолёт
gameplayRouter.select('flying');
// Та же клавиша теперь управляет самолётом
rawInputSource.push(new KeyboardEvent('keydown', { code: 'KeyW' }));
// Через 16ms: ✈️ Plane: KeyW
Когда имеет смысл попробовать Transferum
Библиотека подойдет для:
TypeScript-first проектов — благодаря максимально строгой типизации и compile-time вычислению доступных методов любого трансфера на основе объявленных у него флагов возможностей.
Работы с pull-based источниками данных — polling API, датчиков, хранилищ с PollingProxy.
Смешанных sync/async пайплайнов — в единой модели без ручного преобразования.
Явного flow control — gates, bridges, selectors для runtime-маршрутизации.
Game development / IoT — frame-aligned tickers, idle polling, sensor aggregation.
Устойчивой обработки ошибок — локальная, non-fatal обработка: одна стадия не убивает пайплайн при условии переданного в конфиге обработчика ошибок, ничего не подавляется молча.
Результаты и планы
Библиотека уже используется в двух наших внутренних проектах и показывает свою эффективность. Код доступен на GitHub под лицензией MIT, библиотека не имеет внешних зависимостей и поставляется с подробной документацией (README + API Reference).
В одном из проектов граф состоит из ~80 узлов и стабильно обрабатывает несколько сотен событий в секунду без деградации. На основе этих данных в том числе рендерится 3D-сцена в Babylon.js со стабильным фреймрейтом ~60 FPS без микрофризов.
Тесты библиотеки покрывают не только отдельные трансферы, но и поведение системы в динамике: переподключение мостов, обработку ошибок в длинных асинхронных цепочках, а также разнообразные граничные случаи. Покрытие — 100%.
В дальнейшем планируем реализовать хуки и утилиты для более удобного и нативного использования Transferum с Vue и React. Если они окажутся в достаточной мере переиспользуемыми, оформим в отдельные пакеты-адаптеры.
Буду рад, если вы заглянете в репозиторий, попробуете библиотеку в деле и поделитесь замечаниями — обратная связь поможет сделать Transferum лучше.
P. S. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.
Небольшой повод похвастаться: меня начали звать на технические аудиты не только по работе, но и просто как специалиста.
Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.
У заказчика уже есть работающий продукт примерно на 3000 активных пользователей в месяц. Пользователи покупают подписку и получают доступ к текстам, фотографиям и видео.
Заказчик решил обновить приложение и нанял отдельную команду. Прошло довольно много времени, но внятного результата он так и не увидел.
Разработчики говорят, что проблема в непонятном ТЗ. Заказчик говорит, что команда не отвечает на вопросы, не доводит решения до конца, а то, что показывает, регулярно не работает.
Меня позвали разобраться.
Первым делом я попросил доступ к коду. Код лежит в собственном GitLab. Правда, сам GitLab периодически тоже лежит, поэтому попасть туда получилось не сразу.
Когда доступ появился, меня встретила авторизация через Keycloak.
Напомню: разработчиков трое.
Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.
Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.
Всё это работает на мощностях заказчика. Точнее, периодически работает. То GitLab недоступен, то проблемы с кластером, то ломается ещё что-нибудь. А отдельных людей, которые могли бы постоянно следить за этим зоопарком, нет.
Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.
Frontend вроде бы существует. Но вживую я его до сих пор не видел, только на скриншоте.
Сколько функций действительно готово, тоже непонятно. Приёмочные испытания ещё не начались, потому что критерии приёмки всё ещё согласовывают.
Получается странная картина. Инфраструктура уже сложная. Репозиториев много. Инструментов ещё больше. А общего понимания, что считается готовым продуктом, до сих пор нет.
Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.
Если команда из трёх человек построила инфраструктуру, за которой не успевает следить, значит, сложность уже стала проблемой. Особенно когда она не помогает быстрее выпускать продукт.
Поэтому моя первая рекомендация заказчику простая: упростить инфраструктуру до уровня, который команда реально может поддерживать. Уменьшить количество движущихся частей и сначала научиться стабильно доставлять продукт пользователям.
Забавно, что это полная противоположность истории с The Signal.
Там ребята быстро выкатились на Vercel, но забыли настроить RLS в Supabase. А когда я поднял логи и метрики, мне сказали, что это уже какой-то очень серьёзный подход.
Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.
Обе крайности плохие. Можно месяцами строить идеальную инфраструктуру и не выпустить продукт. А можно выкатиться за вечер, забыв про безопасность, логи и бэкапы.
Нормальный вариант где-то между ними: работающий пользовательский сценарий, понятные критерии готовности, минимальная безопасность, логи, метрики и повторяемый деплой.
Каждый, кто хоть раз пытался записать онлайн-лекцию, созвон по работе или прохождение игры, сталкивался с одной и той же проблемой. Скачиваешь программу, тратишь время, записываешь часовое видео, а на выходе получаешь огромный водяной знак посреди кадра. Или приложение сообщает: «Бесплатный лимит — 5 минут, плати 20 долларов». Мне эта ситуация знакома. По работе приходится писать десятки скринкастов в неделю. За пару лет я перебрал кучу софта — от тяжеловесных комбайнов до мелких плагинов. В этой статье я собрал рабочие способы, которые позволят вам записывать экран без ограничений. Без рекламы, всплывающих окон и требования привязать карту. Способ 1. Быстро и прямо в браузере Иногда устанавливать полноценный софт на ПК банально лень, а на рабочем ноутбуке часто нет прав администратора. В таких случаях выручают браузерные расширения. Раньше все пользовались популярным сервисом Loom, но сейчас его бесплатная версия сильно урезана. Недавно я наткнулся на отличную альтернативу от сервиса автоматической расшифровки Speech2Text. Изначально это мощная платформа для перевода аудио в текст, но разработчики выкатили крутое обновление — встроенный рекордер. Расширение Speech2Text Recorder (https://chromewebstore.google.com/detail/speech2text-recorder/kfblmmakaknmhjecfdgfombhljndkbca?pli=1) позволяет записывать видео вообще без каких-либо лимитов по времени. Можно писать весь экран, отдельное окно или конкретную вкладку Chrome. Качество не режется, видео сохраняется сразу в удобном формате. Никаких платных подписок ради базовых функций от вас не потребуют. Если интересно посмотреть, как этот инструмент работает на практике, авторы выложили короткий видео-обзор инструмента (https://t.me/speech2texts/120) , а в их канале есть подробный пост-инструкция (https://t.me/speech2texts/97) . Для повседневных задач типа «быстро записать баг», «сделать инструкцию коллеге» или «сохранить вебинар» — это сейчас топ-1 решение. Способ 2. Тяжелая артиллерия для стримеров Если нужно не просто записать вкладку, а настроить сложную сцену, наложить несколько источников звука и подключить веб-камеру с хромакеем, ваш выбор — OBS Studio. Это бесплатный софт с открытым кодом. Тут нет ограничений по времени или качеству. Скачать программу можно с сайта(оbs-studio.cоm), так как проект является полностью некоммерческим. Но есть нюанс. OBS имеет крутую кривую обучения. Интерфейс выглядит перегруженным. Если нужно просто нажать одну кнопку и получить файл, вы запутаетесь в источниках и битрейте. Неправильно настроите захват экрана — получите черный экран вместо видео. Но для профессиональных задач мощнее софта нет. Способ 3. Встроенные инструменты систем В современных операционных системах уже по умолчанию присутствуют неплохие встроенные рекордеры. Им не нужен интернет, они не требуют установки стороннего софта и работают отлично прямо «из коробки». В Windows 10 и 11 есть панель Xbox Game Bar. Вызывается комбинацией клавиш Win + G. В ней можно включить запись активного окна. Инструкцию по настройке горячих клавиш можно глянуть здесь (microsoft-support.co.net/gamebar) . Из минусов: панель не умеет записывать рабочий стол целиком, только конкретное запущенное приложение. В macOS всё еще проще. Нажимаете комбинацию Command + Shift + 5, выбираете область экрана и кликаете «Запись». Управлять качеством можно через стандартный проигрыватель, подробнее о фишках системы расписано на портале(apple-guide.infom) . Ограничений по времени нет, видео весит прилично, зато качество идеальное. Способ 4. Онлайн-сервисы без установки Если расширения не подходят, можно использовать облачные платформы. Например, сервис Screen Capture. Вы заходите на страницу(screencapture.ru-net), ставите галочки напротив нужных параметров и нажимаете старт. Метод рабочий, но помните о безопасности. Записывать конфиденциальные данные или рабочие документы через сторонние веб-сайты — идея сомнительная. К тому же, бесплатная версия часто ограничивает разрешение готового ролика. Что выбрать в итоге? Для глобальных проектов, записи игр в высоком разрешении и стриминга — однозначно качайте OBS Studio. Придется потратить вечер на настройки, но это база. Если нужно записать что-то здесь и сейчас, не захламляя систему тяжелыми программами — ставьте расширение от Speech2Text. Это быстро, бесплатно и без ограничений по длине ролика. Встроенные инструменты Windows и Mac хороши для моментальных задач, когда под рукой больше ничего нет. В остальном — выбирайте инструмент строго под свои текущие цели.
Пришла мне вчера ESP32-C3 с OLED 0.42" дисплейчиком. Подключил к Arduino 1.8.19 (электрон версию не брал). Включил, увидел моргающий светодиодик с периодом в 1 сек. Какой-то текст вида "ESP32-C3" и пр. на дисплейчике, ну и положил всё енто в пакетик с китайским ампер-вольтметром (калибрануть его надо - дома точных эталонных тестеров нет - ширпотреб только). Принёс на работу, а дисплейчик того - хана, разбил я его...
Ну да ладно. Похвастался, поплакался, сегодня начал изучать ардуино-программирование (ранее дела не имел), и вот что получил на выхлопе:
1. ESP32, в отличие от ESP8266 имеет под капотом FreeRTOS (мля, задолбали лочить РФ). 2. Как следствие delay() уже не тормозит одноядерный проц, что имеет место в атмегах и ESP8266, а использует vTaskDelay() от операционки, что позволяет сделать адекватной консолидированную многозадачность 3. Есть уже готовые от ОСи мютексы, инхронизацию потоков и пр., в том числе и асинхронный ввод-вывод с портов, что позволяет ожидать событий на GPIO/портах не нагружая проц в цикле.
Скетч, который я сейчас гоняю и далее изучаю (русские комменты мои, на английском с гугла/примеров и т.п.):
И да, синий светодиодик мыргает как полагается.
Буду ковырять далее. Думаю до ассемблера с RISC-V дойду не скоро, но буду стараться закапываться глубже, точнее ниже FreeRTOS. Надеюсь меня хватит надолго играться в енто...
Решил я поиграться в ардуинки. Выбор пал на ESP32-C3 с 0,42-Дюймовым OLED-Модулем за какие-то там 200 руб. Пока оно едет из Китая думаю, дай потыкаюсь со средой разработки. Раньше дела с ней не имел.
Оказывается есть две версии под линухой. Одна на электроне v. 2.3.8 и старая 1.8.19 на Java. Но об ентом я ещё не знал, естественно выбрал поновее и получил засаду - вечно крутится на заставке. Думал наши разрабы АльтЛинухи накосячили с опакечиванием, перепробовал кучу сборок со стороны (не из репов Альта) - везде одно и тоже - вечно крутится заставка. Запустил иде из консоли и увидел туеву хучу ошибок с невозможностью чего-то там скачать. Направление гугления тут же изменилось и выяснилось, что www.arduino.cc лочит россиян из-за Cloudflare (эдакий сервис для защиты сайтов от хакерских атак). Что и и как произошло между Cloudflare и РФ вспоминать не стал и начал думать как пустить Ардуино-ИДЕ через тор-сеть. Придумать не удалось
Вот тогда я и узнал, что разница между старой и новой ИДЕ исключительно в интерфейсе, более того, настроек сети в новой версии я не нагуглил (возможно пальчиками где-то в конфигах и прописывается). А вот в старой версии пожалуйста Файл-->Настройки->Сеть:
При этом все библиотеки и "платы" начали загружаться. И да, версия из репозиториев Альта. Между прочим, ардуинки часто используются не только как хобби, но и в образовательных целях. Но политиканам насрать на это.
Тут поговаривают, что есть приложуха для ПК под названием "Яндекс. Диск" и с 3 июня оно станет платным для персоналок. Точнее по подписке, а не заплатил раз и забыл.
У меня вопрос - этой хренью на компе (речь идёт не о мобилках) кто нибудь пользуется? Я ставил такую вещь клиенту - синхронизация данных в 1С шла через общий яндекс диск, повезло что у клиента POS-терминалы были заряжены на базе Вынь-8.
Что самое интересное - другие облака, тот же мыло.сру такких телодвижений не предпринимают. Более того, у яндекса есть вменяемый WebDAV, который без всяких приложух монтирует облако как локальный диск, у мыла его нету (по крайней мере раньше - сейчас не знаю). В линухе маленький однострочный скрип монтирует моё облако в папку и там пашет всё, в том числе и фоновая синхронизация.
Телодвижения манагеров яндекса не вполне ясны, им же нужно наоборот привлекать клиентов, а не отталкивать, к тому же у них и у других конкурентов есть классическая подсадка на подписку в виде ограничения объёма.
И да. Я в основном пользую буржуйский терабокс - бесплатно 1Тб облака диска, в бесплатной версии идёт ограничение на размер одного файла в 1(ошибся) 4Гб, как у FAT32. Насчёт WebDAV не интересовался - пользую веб-версию. Так что решение яндекса весьма неоднозначно - оно просто оттолкнёт тех немногочисленных пользователей приложухи (которая вполне может собирать телеметрию)
Всё чаще встречаю фразу "навайбкодили". Вот у мну есть скачанные 3 тома "Искусство программирования" от Эрвина Дональда Кнута. Я даже первый его том толком не прошёл по его задачкам на уровне более чем начальный. А у него там есть "задачки со звёздочкой".
Вопрос. Хоть какая-нибудь нейросеть сумела порешать хотя бы с десяток "задач*" не плагиатя то, что уже есть в тырнете?
По английски VirtualBox. Попытаюсь объяснить что енто за зверь и для чего он нужен вообще максимально простым языком. Так что те, кто уже знает что такое виртуализация- могут проходить мимо, разве что в коментах попинать меня за неточности.
Представьте. Сидите Вы на винде и ничего другого не знаете, появляется чел и начинает Вам втирать какие крутые и удобные MacOS или какой нить линух в виде бубунты или Минта. И так хорошо это сделал, что прям совсем-совсем надо попробовать. Можно заплатить "мальчику по вызову", что бы тот накатил на Ваш комп линукс или MacOS. Но при это этом почти наверняка он снесёт винду (дай бог ещё фоточки и хоум-видео сохранит). Ну не покупать же MacBook только ради потыкать MacOS, а вдруг это окажется для Вас вообще неприемлимо?
Вот для этого и есть данная программулина. Она позволяет не трогая Вашу операционную систему запустить другую операционную систему и изучить её. А там уже сами решайте что делать. VirtualBox позволяет эмулировать железо и загружать на нём те же операционные системы. Т.е. это просто программа (на самом деле далеко не просто-программа).
А сейчас немного деталей, так, поверхностно:
Грубая и обобщённая схема как всё пашет
И так, сначала поясню термины:
Host (Physical Machine) - Это то самое железо, т.е. оборудование на котором работает
Host OS - Это как раз Ваша операционка (в тексте выше - любимая Винда).
Virtual Mashine - та самая виртуальная машина на которой будут крутится другие операционные системы. VirtualBox использует для этого QEMU (как раз эмулятор аппаратуры) и на данный момент требует от процессоров Хоста аппаратной поддержки виртуализации (которая есть уже давно).
Guest OS (гостевая операционка) - это как раз то, что мы хотим посмотреть, потыкать, т.е. MacOS, Linux, FreeBSD или вообще MS-DOS для понастальгировать.
Application (приложения) - программы запущенные в гостевой ОС (тот же бравзер Safari).
Guest Additions (гостевые дополнения) - набор программ и драйверов для конкретной гостевой операционки. Можно обойтись и без них, но с ними всё шевелиться будет шустрее, появятся интеграции мыши, клавиатуры, буфер обмена между гостевой операционкой и основной и т.п.
VirtualBox (на схемке выше) - это как раз наш виновник поста, он рулит и педалит виртуальными машинами.
VirtualBox Extension Pack (пакет расширений самой "виртуальной коробки") - например позволяет подключаться к виртуальным машинам с удалённых компов (применимо как раз на серверах) по протоколу RDP, осуществлять загрузку гостевой операционки по сети и многое другое, что обычному пользователю нафиг не нужно. В основном это уже платные приблуды для серверов.
Должен отметить, что "Virtual Mashine" это далеко не чистая программная эмуляция. Большинство операций выполняется на Вашем процессоре напрямую, более того, есть возможность часть Вашего оборудования (USB-порты, видеокарты) как бы сдать в аренду виртуальной машине (при этом этим устройством ничто не должно пользоваться - воровство недопустимо). Например если на компе две видеокарты (одна основная, а вторая на второй монитор транслирует видео-поток с камер наблюдения), то сдать в аренду вторую видюху не выйдет - операционная система хоста не позволит. А вот если никакая программа не будет её использовать, то запросто (на самом деле надо будет позаморачиваться в настройках). В результате самая тормозная часть виртуализации - видео будет работать почти со 100% скоростью видеокарты. То же самое и с USB.
З.Ы. Надеюсь после прочтения вомбатяне не будут впадать в ступор или обморок при слове VirtualBox, потыкал операционку в виртуалке и т.п. И да, мир клином не сошёлся на VirtualBox`е, под своей линухой пользуюсь QEMU+KVM, только VirtualBox наиболее удобен для начинающих. Ну и ивент подходящий. З.З.Ы Как раз вчера вышла новая версия VirtualBox`а 7.2.8, что и навело на мыслю нарисовать ентот пост.
Привет всем! Вот и 3я часть дневника разработки. Хотелось бы поделиться новостями и вектором развития нашего проекта WorldES!
Мы обновили систему камеры — ура! Теперь можно наблюдать за вашим агентом и фокусироваться на нём.
Мы потратили огромное количество времени на масштабирование карты — теперь она стала гораздо больше!
Вместо 50×50 пикселей карта теперь составляет 100х110 пикселей.
Мы обновили систему эмоционального состояния агента. Теперь шанс того, что он вас пошлёт, составляет всего каких-то 25%. Агент стал внимательнее прислушиваться к вашим просьбам. Это сделано для повышения вовлечённости — мы этого не скрываем.
Но вы можете вообще не давать ему команды: он способен сам их находить и выполнять. Сейчас мы сделали упор на графическую составляющую. Стараемся добавлять как можно больше мелких деталей для удобства интерфейса.
Система построек:
Активно работаем над добавлением системы строительства. Пока отправили на прод бета-версию, чтобы собрать как можно больше данных для отладки системы и базового обучения. Более детально будем прорабатывать её уже на основе полученных данных. Система "Планета". Теперь карта не является ограниченным полотном — агенты больше не упираются в невидимые стены. Агент может выйти с одной стороны экрана и появиться с другой. Это открывает возможности для масштабирования карты в будущем.
Доработали баланс "Дерево развития". Теперь агент получает опыт именно за те действия, которыми он занимается. Ранее система распределяла опыт по всем направлениям.
Вектор развития до конца "Апреля":
1.Увеличить вовлеченность пользователя, различными игровыми ситуациями и возможностями. 2.Добавить полноценную симуляцию строительства, захвата территорий. 3.Проработать систему хищников и общего животного мира.
Этот проект мы делаем своими силами, и решили поблагодарить тех, кто поддержит нас на Boosty — добавили соответствующую плашку в чате.
Всем спасибо, кто прочитал этот пост! Мы продолжаем развивать проект и благодарим вас за участие — вы мотивируете нас двигаться дальше!
Всем привет! Хотел бы обновить "Дневник разработки" часть 2.
И поделиться с Вами что обновили в симуляции WorldES.
1.Дерево навыков.
60 дополнительных параметров для развития навыков. Вы сможете помочь Вашему агенту развиваться и как можно дольше и лучше выживать. Система не сбрасывает очки навыков. Они остаются у Вашего агента навсегда.
2.Система заданий
Эти задания, позволяют повышать уровень взаимодействия и быстрее обучаться делать полезные действия. В планах, чтобы Вы как создатель агента, могли давать ему задание (цель), чтобы на этих данных агент, обучался сам ставить себе цели на будущее (Основать свое поселение).
Немного фана, таблицу лидеров, о ней даже подробно писать не буду. Там и все так понятно.
Теперь перейдем к физическим свойствам и симуляции: 1) Мы доработали систему термодинамики. Теперь полноценно работает 2-й закон, который гласит: "Тепло самопроизвольно передаётся только от более тёплого тела к более холодному, а не наоборот."
Добавлена температура тела и симуляция её поведения. В ближайшие 1000 прогонов закон должен корректно симулироваться.
2) Запахи и свет. Наши агенты обрели возможность видеть свет и чувствовать запахи. Если кто-то сажает ягоды, или разбивает костёр, по карте с определенным направлением ветра так же развивается запах костра. На него могут прийти другие агенты.
3) Животные. Активно разрабатываем систему животных, вводим виды (Дружественные, агрессивные и т.д).
По данному блоку могу мало чем поделиться, т.к этот блок требует детальной проработки и сил. Сейчас активно работаем над тем, чтобы обучения агента проходило правильно и максимально реалистично.
Про закон Фурье и прочие умные штуки, я напишу уже в следующем дневнике) А так, если Вам интересно наблюдать за проектом! Буду рад Вашей поддержке! Создайте своего Агента, обучайте его, следите за ним и мы вместе создадим что-то большее чем обычная симуляция жизни.
Есть идея, выложить весь исходный код в открытый доступ. Но пока думаю над этим.
Иногда в симуляции появляются неожиданные паттерны. Например, выживает не самый быстрый, а тот, кто экономит свои ресурсы.Сейчас работаю над добавлением животных, чтобы агенты получали больше возможности на поиск пропитания.И в планах внедрить систему управления за агента, ты пишешь ему задачу, он в зависимости от настроения может начать её делать или нет.
Зачем я вообще это делаю?
Мне интересно, можно ли сделать систему, где:
нет заранее прописанных победителей,
нет сценария,
Без «уровней». Без «сюжета». Просто среда и законы. Что-то типо своего рогалика, только в большом масштабе.
Буду рад если вы тоже примите участие в эксперименте! Создадите своего агента и поможете получать как можно больше данных для обучения и развитие проекта.
Во второй части, буду писать ответы на вопросы в расширенном варианте (если они будут), и более подробно описывать функционал.
До этого я честно пытался делать то же самое в чатах OpenAI / Grok / DeepSeek. Сценарий всегда один: контекст расползается, требования приходится повторять, а иногда чат просто зависает — и я делаю всё заново.
После этого я перестал относиться к LLM как к переписке и начал относиться как к рабочему месту: проект + файлы + правила + Git.
Мой принцип
Мне не нужен «идеальный промпт». Мне нужен процесс, который не убивает мой день, когда модель поехала не туда.
Хак: rules можно дописывать прямо по ходу работы — я часто прошу агента «сформулируй правило, чтобы мы больше так не делали», и добавляю его в проект.
III. Положи «источники правды» в репу
Тут мой единственный принцип: всё, что я устал повторять — я выношу в файлы.
Пример структуры, которую я делаю для большинства задач:
README.md — одна страница «что строю и зачем». docs/ — требования и решения (чтобы не хранить их в голове и в чате).
IV. Режимы: я не жму Agent сразу
Я использую три режима:
Ask — когда хочу разобраться/проверить идею и ничего не ломать.
Plan — когда задача больше пары часов: сначала план и вопросы.
Agent — когда план ок: он уже правит файлы и двигает задачу.
И два хака, которые у меня реально помогают:
Хак 1: я спрашиваю у самого агента в Cursor, какую модель лучше взять под мою задачу.
Хак 2: я стараюсь не использовать авто-режим — автоматически Cursor часто подбирает модель неудачно.
V. Бизнес‑дока → Tech Spec
Я не начинаю с “какой стек лучше”.
У меня уже есть привычный стек (я писал про него тут: https://t.me/debug_leg/580), и мой первый вопрос к Cursor другой: могу ли я остаться на нём под эти бизнес‑требования или мне придётся делать иначе (и почему).
Решил я давеча сменить привычный до боли арч линукс в оболочкой LXQt на отечественный Аlt Linux c КДЕ. Скажу сразу - вся настройка и установка была мышкодрыгательной, клавиатура использовалась только для ввода логинов/паролей юзеров.
В домашней сети на своих компах/поддиванных_локалхостах ипспользую статик-IP, всё что подключено по кабелю - в статике. Мне так удобнее. Ну установил, я Альт, посидел на нём пару дней - понравилось, решил оставить. Ну раз так, то почему бы и не перенастроить на статик свой комп, как и всё остальное. Сказано - делаем. Естественно хочется сделать всё мышой, а не через консоль.
И тут настаёт облом - как только выставляю IPшник 172.16.0.75 сети нет, роутер ростелекомовский виснет - приходится перегружать. Не могу ничерта понять. Ладно, консоль так консоль. Там так же нифига не выходит. Долблюсь часа три, психую. В сторону "Базальта" (разработчика этого дистра) в уме уже высказал весь свой нецензурный лексикон.
Выпив ещё одну баклажку пивной мочи и обкурвшись вспоминаю, что этот IPшник занят недобуком в качестве "сервака" под столом, а основной, стационарный комп имел IPшник 172.16.0.25.
Теперь всё что я высказывал в сторону "Базальта" я начал применять уже к себе.
Таким образом получается, что установку и настройку можно выполнить исключительно по-виндошному - мышой, минимизируя использование клавиатуры и не запуская текстовую консоль вообще. Думаю распространённые дистры вроде бубунты, минта и пр. так же умеют (давно их не тыкал). Что понравилось в Альте (когда я его ещё в виртуалке тыкал-присматривался) КДЕшный интерфейс сделан максимально похожим на виндошный. Нет, он не копирует темы, значки и пр. Но меню, панель, систрей сделаны как можно ближе к седьмой винде, поведение окон и хоткеи виндошные (изменил только Ctrl-Alt-Del, что бы он запускал Qps - понравился мне этот менеджер процессов). Примерно такой же подход в Астра-линукс с оболочкой Fly. Тут маркетологи молодцы - не стали отпугивать потенциальных юзеров непривычным интерфейсом как в Gnome или всеми наворотами, которые предоставляет KDE (в Альте по дефолту как в винде - один рабочий стол и одна комната).
