Интересно, рассматривали ли вы возможность использования UIO-драйвера вместо написания полноценного TTY-драйвера? Это могло бы упростить доступ к регистрам из пользовательского пространства без необходимости внедрения в ядро. Также, как насчет использования более высоких скоростей передачи данных через UARTLite? 9600 бод может быть узким местом в некоторых приложениях. В целом, статья вдохновляет на эксперименты с FPGA и Linux.
А есть ли информация, насколько глубоко Gemini понимает контекст приложения при генерации? Учитывает ли, например, бизнес-логику, зависимости между экранами или ограничения API? Или это всё-таки больше про UI-«наброски» и boilerplate-код? Интересно, насколько результат жизнеспособен без ручной доработки.
Тут «перехватывается» использовано не случайно речь о том, что запрос уходит за пределы контролируемой среды.
если DNS-трафик не шифруется (UDP/53), он действительно может быть перехвачен или подменён на любом участке маршрута до резолвера. Особенно в открытых или недоверенных сетях. + некоторые приложения сами перенаправляют DNS-запросы, минуя системные настройки это уже silent hijack. Так что в статье, да и в контексте безопасности формулировка вполне обоснованна. Рекомендую заглянуть RFC 7626 — там эта угроза тоже подробно рассматривается.
Идея прикольная, но если смотреть с позиции более серьёзных задач polling через Tg API не очень надёжный путь. Задержки, лимиты, отсутствие нормального QoS всё это начинает мешать, как только ты выходишь за рамки “поиграться вечером”.
Для чего-то более стабильного я бы всё же смотрел в сторону MQTT, где есть и real-time, и надёжность, и меньше головняка на больших объемах. Но как концепт — кайф, простота подкупает. Можно даже в учёбе использовать, чтобы втянуться в тему IoT.
Прочитав статью, задумался: насколько сильно опыт автора в создании ЭВП перекликается с принципами устойчивого производства? Использование стекла от ЛДС и самодельного оборудования это не только проявление инженерной смекалки, но и шаг к осознанному потреблению. Возможно в будущем, такие проекты могут стать основой для образовательных программ, где студенты учатся не только технике, но и экологической ответственности. Особенно когда еще какую нибудь популярную деталь делают, типа «хабр», можете еще сделать какой нибудь логотип или можно попробовать эквалайзер запихнуть
конечно согласен ситуация, когда устройства из коробки открыты в интернет с таким логином , это не просто халатность, а прямая угроза. Обычный пользователь, купив «умный» девайс, ожидает, что базовые настройки безопасности уже учтены. Но реальность ха-ха такова: производители часто экономят на элементарных мерах, превращая гаджеты в не пойми что. Как ботнет Mirai, который парализовал пол-интернета через камеры и роутеры с дефолтными паролями. Если даже после таких коллапсов рынок не меняется это системный провал. Лично я считаю, что пора вводить уголовную ответственность для вендоров за умышленные дыры в безопасности. Пока штрафы меньше прибыли от продаж, «админы» останутся в каждом умном чайнике.
Есть аспект, который часто упускают: где грань между ответственностью пользователя и обязанностью регуляторов? Например, после истории с 28 тыс. принтеров, печатающих мемы, стало ясно, что многие компании даже не меняют пароли по умолчанию. Но если пользователи годами игнорируют базовые меры, а производители экономят на Security by Design не пора ли ввести обязательную сертификацию IoT-устройств, как это сделано в авиации или медицине? В ЕС уже пытаются внедрить Cyber Resilience Act, но хватит ли таких инициатив, чтобы заставить рынок выпускать устройства с изолированными компонентами и автоматическими обновлениями или мы обречены на вечную гонку, где умный чайник 2025 года взламывается через BLE-ключ, как принтер из 90-х?
Мне вот интересно как вы думаете, что эффективнее жёсткие законы с штрафами за уязвимости или публичное давление через рейтинги безопасности типа «CyberScore для IoT»? Может, пора создать аналог краш-тестов, но для умных устройств xd
Еще слышал историю как взломали умные инсулиновые помпы через уязвимость в Bluetooth, производитель заявил: «Это пользователи не обновили прошивку». Но как требовать ответственности от пациентов, если обновление стирает их настройки и требует перепрошивки через ПК? Где тут грань между правом на жизнь и правом на безопасность?Или другой пример: если ваш «умный» замок взломают через дефолтный пароль, а злоумышленник ограбит дом — кто виноват? Вы, производитель или регулятор, который не запретил продажу таких замков?
P.S. пора бойкотировать бренды, которые десятилетиями игнорируют CVE
Интересный подход с docstring, но пара вопросов: Если Copilot тянет контекст из открытых вкладок, как не подсунуть ему случайно какой-нибудь config с ключами? Есть ли способ явно исключать файлы из анализа?
Пробовали такую же схему в Cursor или других ассистентах? Говорят, у них гибче настройки контекста — может, там проще зашить гайдлайны? И кстати, а если в проекте 50+ файлов открыты — Copilot вообще перестает адекватно работать, или просто берет ближайшие по редактированию?
Вы поднимаете критически важный вопрос: корень конфликтов действительно уходит в культурный код организации и систему ценностей, которые формируют поведенческие паттерны. Соглашусь, что в среде, где доминируют страх, конкуренция и «силовая» мотивация, любые тренинги по soft skills становятся косметическим ремонтом на фоне системного кризиса.
Однако здесь есть нюанс: культура — это не монолит, а динамичная система. Да, сотрудники действуют в рамках заданных «правил игры» (KPI, гонка за бонусами, вертикальная ответственность), но и сами эти правила можно менять
Да, в нашем случае данные обновлялись настолько быстро, что курсор не успевал актуализироваться и вообще так выходило что часть записей терялась между страницами. В результате мы после планерки решили перейтии на keyset-пагинацию, зафиксировав снэпшот транзакции через REPEATABLE READ с использованием неизменяемого идентиф. В целом из плюсов это позволило сократить время отклика до 150 мс, ноо потребовалось доработать клиентскую логику для корректной передачи и сохранения состояния курсора. Например, добавили хэширование последнего полученного ID для предотвращения конфликтов.
При работе с большими объёмами данных в PostgreSQL запросы с OFFSET 1M стали вызывать задержки в несколько секунд. Как я понимаю и читал, курсорная пагинация должна как то решать эту проблему. Действительно ли это оптимальное решение?
стоят рядом с яйцилопом с гравицапой
Интересно, рассматривали ли вы возможность использования UIO-драйвера вместо написания полноценного TTY-драйвера? Это могло бы упростить доступ к регистрам из пользовательского пространства без необходимости внедрения в ядро. Также, как насчет использования более высоких скоростей передачи данных через UARTLite? 9600 бод может быть узким местом в некоторых приложениях. В целом, статья вдохновляет на эксперименты с FPGA и Linux.
А есть ли информация, насколько глубоко Gemini понимает контекст приложения при генерации? Учитывает ли, например, бизнес-логику, зависимости между экранами или ограничения API? Или это всё-таки больше про UI-«наброски» и boilerplate-код? Интересно, насколько результат жизнеспособен без ручной доработки.
Тут «перехватывается» использовано не случайно речь о том, что запрос уходит за пределы контролируемой среды.
если DNS-трафик не шифруется (UDP/53), он действительно может быть перехвачен или подменён на любом участке маршрута до резолвера. Особенно в открытых или недоверенных сетях. + некоторые приложения сами перенаправляют DNS-запросы, минуя системные настройки это уже silent hijack. Так что в статье, да и в контексте безопасности формулировка вполне обоснованна. Рекомендую заглянуть RFC 7626 — там эта угроза тоже подробно рассматривается.
Идея прикольная, но если смотреть с позиции более серьёзных задач polling через Tg API не очень надёжный путь. Задержки, лимиты, отсутствие нормального QoS всё это начинает мешать, как только ты выходишь за рамки “поиграться вечером”.
Для чего-то более стабильного я бы всё же смотрел в сторону MQTT, где есть и real-time, и надёжность, и меньше головняка на больших объемах. Но как концепт — кайф, простота подкупает. Можно даже в учёбе использовать, чтобы втянуться в тему IoT.
Прочитав статью, задумался: насколько сильно опыт автора в создании ЭВП перекликается с принципами устойчивого производства? Использование стекла от ЛДС и самодельного оборудования это не только проявление инженерной смекалки, но и шаг к осознанному потреблению. Возможно в будущем, такие проекты могут стать основой для образовательных программ, где студенты учатся не только технике, но и экологической ответственности. Особенно когда еще какую нибудь популярную деталь делают, типа «хабр», можете еще сделать какой нибудь логотип или можно попробовать эквалайзер запихнуть
конечно согласен ситуация, когда устройства из коробки открыты в интернет с таким логином , это не просто халатность, а прямая угроза. Обычный пользователь, купив «умный» девайс, ожидает, что базовые настройки безопасности уже учтены. Но реальность ха-ха такова: производители часто экономят на элементарных мерах, превращая гаджеты в не пойми что. Как ботнет Mirai, который парализовал пол-интернета через камеры и роутеры с дефолтными паролями. Если даже после таких коллапсов рынок не меняется это системный провал. Лично я считаю, что пора вводить уголовную ответственность для вендоров за умышленные дыры в безопасности. Пока штрафы меньше прибыли от продаж, «админы» останутся в каждом умном чайнике.
Есть аспект, который часто упускают: где грань между ответственностью пользователя и обязанностью регуляторов? Например, после истории с 28 тыс. принтеров, печатающих мемы, стало ясно, что многие компании даже не меняют пароли по умолчанию. Но если пользователи годами игнорируют базовые меры, а производители экономят на Security by Design не пора ли ввести обязательную сертификацию IoT-устройств, как это сделано в авиации или медицине? В ЕС уже пытаются внедрить Cyber Resilience Act, но хватит ли таких инициатив, чтобы заставить рынок выпускать устройства с изолированными компонентами и автоматическими обновлениями или мы обречены на вечную гонку, где умный чайник 2025 года взламывается через BLE-ключ, как принтер из 90-х?
Мне вот интересно как вы думаете, что эффективнее жёсткие законы с штрафами за уязвимости или публичное давление через рейтинги безопасности типа «CyberScore для IoT»? Может, пора создать аналог краш-тестов, но для умных устройств xd
Еще слышал историю как взломали умные инсулиновые помпы через уязвимость в Bluetooth, производитель заявил: «Это пользователи не обновили прошивку». Но как требовать ответственности от пациентов, если обновление стирает их настройки и требует перепрошивки через ПК? Где тут грань между правом на жизнь и правом на безопасность?Или другой пример: если ваш «умный» замок взломают через дефолтный пароль, а злоумышленник ограбит дом — кто виноват? Вы, производитель или регулятор, который не запретил продажу таких замков?
P.S. пора бойкотировать бренды, которые десятилетиями игнорируют CVE
Интересный подход с docstring, но пара вопросов: Если Copilot тянет контекст из открытых вкладок, как не подсунуть ему случайно какой-нибудь config с ключами? Есть ли способ явно исключать файлы из анализа?
Пробовали такую же схему в Cursor или других ассистентах? Говорят, у них гибче настройки контекста — может, там проще зашить гайдлайны? И кстати, а если в проекте 50+ файлов открыты — Copilot вообще перестает адекватно работать, или просто берет ближайшие по редактированию?
Вы поднимаете критически важный вопрос: корень конфликтов действительно уходит в культурный код организации и систему ценностей, которые формируют поведенческие паттерны. Соглашусь, что в среде, где доминируют страх, конкуренция и «силовая» мотивация, любые тренинги по soft skills становятся косметическим ремонтом на фоне системного кризиса.
Однако здесь есть нюанс: культура — это не монолит, а динамичная система. Да, сотрудники действуют в рамках заданных «правил игры» (KPI, гонка за бонусами, вертикальная ответственность), но и сами эти правила можно менять
Да, в нашем случае данные обновлялись настолько быстро, что курсор не успевал актуализироваться и вообще так выходило что часть записей терялась между страницами. В результате мы после планерки решили перейтии на keyset-пагинацию, зафиксировав снэпшот транзакции через REPEATABLE READ с использованием неизменяемого идентиф. В целом из плюсов это позволило сократить время отклика до 150 мс, ноо потребовалось доработать клиентскую логику для корректной передачи и сохранения состояния курсора. Например, добавили хэширование последнего полученного ID для предотвращения конфликтов.
При работе с большими объёмами данных в PostgreSQL запросы с OFFSET 1M стали вызывать задержки в несколько секунд. Как я понимаю и читал, курсорная пагинация должна как то решать эту проблему. Действительно ли это оптимальное решение?