Нет, ведь можно угнать сессионные идентификаторы вместе с ключами - для серверов Telegram это будет выглядеть, как если бы пользователь просто сменил свой IP, что вполне может произойти при переключении между мобильной сетью и wi-fi.
Если марку невозможно связать с покупателем, то отправитель может написать в поле "от кого" чужой адрес и кинуть конверт в почтовый ящик поблизости с ним, при этом оставаясь анонимным.
Сейчас у самого популярного инстанса Synapse есть проблема - matrix.org для внешних по отношению к нему пользователям показывает всех в состоянии "offline". Не будет ли у Beeper той же проблемы, когда нагрузка будет сопоставима?
А есть ли хоть какая-нибудь совместимость между вашими процессорными модулями и модулями других производителей, например того же Стартеркита? Понятно, что на вашей плате есть уникальная периферия, но заработает ли хотя бы питание и UART-консоль?
Я предлагаю воспользоваться инструментами (запросом к системе сборки, кнопкой references в IDE, глобальным code search), чтобы найти все проекты и поправить их. А потом запустить тесты, чтобы убедиться, что не стало хуже.
Знать своего клиента (хотя бы приблизительно) всегда полезно, иначе разработчики базовых компонентов начнут изобретать сферических коней в вакууме вместо того, что на самом деле нужно, а клиенты - использовать разрабатываемые системы не так, как задумано.
Это удобно с перспективы того, кто библиотеки использует и доверяет им, но неудобно тем, кто за них отвечает.
Если, например, нужно переложить поле из одной структуры в другую, что повлияет на вызывающий библиотеку код, то не получится одним коммитом всё сразу исправить. Будут какие-то промежуточные состояния, когда всё сломано - в библиотеке поле уже в новом месте, а в приложении - ещё нет, и оно теперь не проходит тесты (или совсем не собирается).
В ответственность того, кто меняет, входит изменение всех мест, где этот интерфейс используется. В итоге получается атомарное изменение - всё в одном коммите. И тесты на нём либо прошли, либо нет.
А как быть с базовыми (инфраструктурными) библиотеками, улучшение которых приносит пользу всем проектам? Аллокаторы, настройки системы сборки, конфигурации, авторизации, мониторинга, service discovery.
Если кто-то смог привнести баг, который вызвал последствия в соседнем проекте, значит в этом проекте недостаточно тестов. Досадно, но после исправления бага и увеличения тестового покрытия, а также принятия мер по искоренению появления проблем такого же класса в будущем (например, перенастройкой линтера, фаззера или изменения правил ревью для директории) растёт качество кода всего монорепозитория.
Ещё полезный эффект - появление глобального отношения порядка. Всегда можно сказать, что какой-то код влили в trunk в такой-то момент времени, и это позже или раньше какого-то другого кода. Это удобно, чтобы описывать правила вида "мы не поддерживаем совместимость по ABI такой-то системы дольше N коммитов и M времени" или "нельзя запускать на проде код старее коммита X".
В Alpine Linux есть режим diskless, который делает то же самое - initramfs ставит из репозитория (сетевого или локального) пакеты и не переключается на традиционный root, оставаясь полностью в памяти.
Для сохранения изменений есть инструмент lbu, который создаёт новый пакет, содержащий всё то, что отсутствует в уже установленных пакетах (обычно это конфиги) и зависящий от world (списка уже установленных пакетов). Таким образом, можно сделать единый загрузочный носитель для множества серверов - они будут загружать одно и то же ядро, один и тот же initramfs, но далее специализироваться, устанавливая (согласно своему hostname) нужный lbu. На реальном железе такая "переустановка" на каждую перезагрузку занимает всего пятую часть всего процесса загрузки - apk достаточно быстрый пакетный менеджер, а openrc умеет параллельно поднимать сервисы.
Самый минималистичный - это тот, который сделан под конкретное применение на конкретном железе; современное ядро с сетью и минимальным юзерспейсом можно в 6M RAM уместить, загружаться сможет с дискеты на 2.8M. Если чуть более общего назначения, то OpenWrt, современные версии с выключенным вебинтерфейсом неплохо чувствуют себя на 48M, более старые можно использовать на устройствах с 32M.
Если в организации уже есть устройства от MikroTik и средства на покупку лицензии, то можно и RouterOS рассмотреть.
А сложно ли начать такое сотрудничество и стать легальным VPN, если нет юрлица в РФ? Например, кто-то хочет сделать VPN для самого себя, и очень нужны выгрузки из РКН, чтобы заблокировать для себя запрещённые ресурсы, чтобы случайно на них не зайти.
Обычные системники можно запитать через устройства типа picoPSU, если они потребляют меньше 200W. Ещё на AliExpress есть различные мини-компьютеры (в основном на SoC от Intel), которые питаются от 12V.
В ГК РФ, статье 1280 написано "если иное не предусмотрено договором с правообладателем". Я совсем не юрист, но понимаю это так, что правообладатель может в EULA/ToS запретить править свой бинарник.
Тут, правда, интересно другое - даже если мне запретили вносить изменения в продукт, могу ли я достичь аналогичного эффекта, внося изменения в среду исполнения, например в ОС, прошивку или аппаратуру?
Использую как тонкий клиент через CRD для доступа к Linux-машине. Работает проброс звука и смена разрешения экрана клиента (при подключении/отключении внешнего монитора), не работает проброс USB-устройств. Производительности CRD хватает, чтобы смотреть youtube через удалённый браузер.
Нет, ведь можно угнать сессионные идентификаторы вместе с ключами - для серверов Telegram это будет выглядеть, как если бы пользователь просто сменил свой IP, что вполне может произойти при переключении между мобильной сетью и wi-fi.
Если марку невозможно связать с покупателем, то отправитель может написать в поле "от кого" чужой адрес и кинуть конверт в почтовый ящик поблизости с ним, при этом оставаясь анонимным.
Не решится ли проблема с авторизацией вот этим кодом? Год назад на Хабре была статья про оболочку над электронным дневником.
Сейчас у самого популярного инстанса Synapse есть проблема - matrix.org для внешних по отношению к нему пользователям показывает всех в состоянии "offline". Не будет ли у Beeper той же проблемы, когда нагрузка будет сопоставима?
Не проверял покупкой, но на странице eternalhost "вечные" тарифы ещё есть: за 7800, 15600 и 31200 рублей. Я что-то упустил?
А есть ли хоть какая-нибудь совместимость между вашими процессорными модулями и модулями других производителей, например того же Стартеркита? Понятно, что на вашей плате есть уникальная периферия, но заработает ли хотя бы питание и UART-консоль?
Я предлагаю воспользоваться инструментами (запросом к системе сборки, кнопкой references в IDE, глобальным code search), чтобы найти все проекты и поправить их. А потом запустить тесты, чтобы убедиться, что не стало хуже.
Знать своего клиента (хотя бы приблизительно) всегда полезно, иначе разработчики базовых компонентов начнут изобретать сферических коней в вакууме вместо того, что на самом деле нужно, а клиенты - использовать разрабатываемые системы не так, как задумано.
Это удобно с перспективы того, кто библиотеки использует и доверяет им, но неудобно тем, кто за них отвечает.
Если, например, нужно переложить поле из одной структуры в другую, что повлияет на вызывающий библиотеку код, то не получится одним коммитом всё сразу исправить. Будут какие-то промежуточные состояния, когда всё сломано - в библиотеке поле уже в новом месте, а в приложении - ещё нет, и оно теперь не проходит тесты (или совсем не собирается).
В ответственность того, кто меняет, входит изменение всех мест, где этот интерфейс используется. В итоге получается атомарное изменение - всё в одном коммите. И тесты на нём либо прошли, либо нет.
А как быть с базовыми (инфраструктурными) библиотеками, улучшение которых приносит пользу всем проектам? Аллокаторы, настройки системы сборки, конфигурации, авторизации, мониторинга, service discovery.
Если кто-то смог привнести баг, который вызвал последствия в соседнем проекте, значит в этом проекте недостаточно тестов. Досадно, но после исправления бага и увеличения тестового покрытия, а также принятия мер по искоренению появления проблем такого же класса в будущем (например, перенастройкой линтера, фаззера или изменения правил ревью для директории) растёт качество кода всего монорепозитория.
Ещё полезный эффект - появление глобального отношения порядка. Всегда можно сказать, что какой-то код влили в trunk в такой-то момент времени, и это позже или раньше какого-то другого кода. Это удобно, чтобы описывать правила вида "мы не поддерживаем совместимость по ABI такой-то системы дольше N коммитов и M времени" или "нельзя запускать на проде код старее коммита X".
В Alpine Linux есть режим diskless, который делает то же самое - initramfs ставит из репозитория (сетевого или локального) пакеты и не переключается на традиционный root, оставаясь полностью в памяти.
Для сохранения изменений есть инструмент lbu, который создаёт новый пакет, содержащий всё то, что отсутствует в уже установленных пакетах (обычно это конфиги) и зависящий от world (списка уже установленных пакетов). Таким образом, можно сделать единый загрузочный носитель для множества серверов - они будут загружать одно и то же ядро, один и тот же initramfs, но далее специализироваться, устанавливая (согласно своему hostname) нужный lbu. На реальном железе такая "переустановка" на каждую перезагрузку занимает всего пятую часть всего процесса загрузки - apk достаточно быстрый пакетный менеджер, а openrc умеет параллельно поднимать сервисы.
По поводу пакетов:
Самый минималистичный - это тот, который сделан под конкретное применение на конкретном железе; современное ядро с сетью и минимальным юзерспейсом можно в 6M RAM уместить, загружаться сможет с дискеты на 2.8M. Если чуть более общего назначения, то OpenWrt, современные версии с выключенным вебинтерфейсом неплохо чувствуют себя на 48M, более старые можно использовать на устройствах с 32M.
Если в организации уже есть устройства от MikroTik и средства на покупку лицензии, то можно и RouterOS рассмотреть.
А не лучше ли то же самое делать на Alpine? Пакетов сильно больше, пользователей (пусть и в "контейнерном", а не "системном" исполнении) тоже больше.
Оперативки там действительно 128M, а вместо диска используется NFS-клиент (и сервер 10.42.100.60).
А что тут не так? Завод скорее всего получает готовую топологию микросхемы, а не исходники - без ключей и документации чип может оказаться бесполезен.
А сложно ли начать такое сотрудничество и стать легальным VPN, если нет юрлица в РФ? Например, кто-то хочет сделать VPN для самого себя, и очень нужны выгрузки из РКН, чтобы заблокировать для себя запрещённые ресурсы, чтобы случайно на них не зайти.
Обычные системники можно запитать через устройства типа picoPSU, если они потребляют меньше 200W. Ещё на AliExpress есть различные мини-компьютеры (в основном на SoC от Intel), которые питаются от 12V.
В ГК РФ, статье 1280 написано "если иное не предусмотрено договором с правообладателем". Я совсем не юрист, но понимаю это так, что правообладатель может в EULA/ToS запретить править свой бинарник.
Тут, правда, интересно другое - даже если мне запретили вносить изменения в продукт, могу ли я достичь аналогичного эффекта, внося изменения в среду исполнения, например в ОС, прошивку или аппаратуру?
Использую как тонкий клиент через CRD для доступа к Linux-машине. Работает проброс звука и смена разрешения экрана клиента (при подключении/отключении внешнего монитора), не работает проброс USB-устройств. Производительности CRD хватает, чтобы смотреть youtube через удалённый браузер.
Те смартфоны на Android, что есть у меня, умеют автоматически включаться, когда должен сработать будильник.