Вообще у DisplayPort есть спецификация Hot Plug Detect, другое дело, что на уровне ОС это реализовано странно (отсоединив и присоединив один монитор это будет добавлением другого устройства с повторной полной инициализацией). Ну и, похоже, не все производители графических ускорителей поддерживают (хотя физически есть линия, изначально предназначенная для определения, присутствует ли устройство).
С VGA тоже были странности: обычное поведение — это устройство может быть подключено/отключено на горячую, но только если при загрузке BIOS присутствовало. Что, несомненно, является ещё каким архаизмом (как и сам VGA). Не вникал, но подозреваю, что связано с тем, что управление низкоуровневыми прерываниями в угоду совместимости не трогали с тех самых времён.
Есть 600 человек, если мы гарантированно спасаем 200 человек, то судьба остальных 400 нам неизвестна, в условиях задачи ничего об этом не сказано. Если нам удалось спасти 300, то утверждение о том, что 200 спасены является верным. Тут ИИ всё верно оценил, вопрос к постановке задачи.
Так и пусть сливает холодную. Если есть горячий теплоноситель в питающей магистрали, то пусть он и заполняет калорифер, попутно нагревая его. Можно сливать в резервуар с поплавковым клапаном, на случай, если температура в самой магистрали аварийно снизилась, но тогда уже речь про множественные отказы независимых систем, где вероятность совместного отказа крайне невысока.
Почему нельзя просто поставить клапан, который при снижении температуры носителя до 5-6 градусов автоматически осуществит аварийный сброс? Механический, если такой бывает или электромеханический с автономным питанием.
Почему бы стрелки не заменить на стик? Едва ли кто-то пользуется комбинациями, где задействовано более одной стрелки за раз. Как вариант ещё - это "качающийся" свитч: по поведению не отличается от остальных, так же прижимается, но без отклонения не имеет действия никакого (либо работает как ctrl т.к. это достаточно безобидная клавиша в случае ошибочного нажатия). При отклонении работает как соответствующая стрелка. Вроде идея на поверхности, однако почему-то до сих пор не встречал имплементацию.
Что если добавить к своей WiFi сети AP в режиме клиента (в качестве workaround-а) и подключиться к регистратору, не отправляя на него маршрут по умолчанию?
А вообще регистраторы — то ещё зло в плане интеграции с другими устройствами: лет 15 назад могли уже делать поддерживающие облако регистраторы, но, видимо, никому не надо. Из года в год характеристики не развиваются вовсе, меняется только дизайн корпуса и цена. А если с интеграцией в зеркало заднего вида, так и вовсе беда с качеством у всех, ни одного приличного производителя.
Но в случае с колонкой вообще кейс сложнее: несколько членов семьи подключаются к одному устройства с разных смартфонов, разные смартфоны при этом сами подключаются к разным колонкам, т.е. в любом случае человеку требуется подтвердить что и куда он собирается подключить.
Довольно простой случай: семья из 2 человек (условно Аарон и Сара), 2 автомобиля с мультимедиа системами (условно Audi и BMW). Аарону необходимо поехать в офис т.к. он забыл важный документ на столе, Сара решила воспользоваться свободным временем и поехать в супермаркет. Сегодня Аарон решил воспользоваться BMW, а Сара Audi (т.к. её попутно необходимо заправить). Оба выходят, погружаются в автомобили, мультимедиа стартуют и там и там, ищут bluetooth pair, находят, подключаются... не туда. Просто вчера Аарон катался на Audi, поэтому та система помнит последнее подключение от его смартфона, а не от её. А т.к. автомобили находятся на соседних парковочных местах, то и уровень сигнала от обоих устройств достаточно мощный.
Сумбурное что-то: WiFi — это L2, сеть — это L3, которая может быть развёрнута в т.ч. поверх WiFi в качестве канала. Создавать точку доступа на смартфоне и подключаться к ней объективом — сейчас бы для этого использовался какой-нибудь профиль Bluetooth. Ранее подобное подключение использовалось, например, для ELM адаптеров, но даже там было удобнее: сам адаптер служил точкой доступа (а единственное, что неудобно, так это то, что смартфоны умеют подключаться только к одной единственной сети, поэтому доступ к Интернет пропадал при использовании адаптера, поэтому уместнее использовать bluetooth, а серверной стороной служит смартфон, но раньше необходимые профили отсутствовали у продукции Apple, поэтому приходилось городить workaround-ы).
Лично я ожидал увидеть более одного производителя модулей. Эдакий отраслевой стандарт. Чтобы можно было ноутбук 5-8-летней давности модернизировать актуальным железом с актуальными интерфейсами. Плюс в качестве рабочей лошадки гибкость в выборе интерфейсов - довольно удобно, когда нужно в разных поездках подключаться к разным системам. Удобно, когда не сидишь где-то на технологической площадке телекома площадью один квадратный метр посреди птичьего гнезда из кабелей и адаптеров. Но модулей modbus, CAN или 1wire, напимер, я что-то не вижу в любом случае.
Как раз наоборот, чтобы избавить бекэндера от задачи поиска контрастных цветов и делегировании этого фронтендеру. Ранее, иногда, всё же требовалось, чтобы цветовые схемы динамически строились (когда кастомер сам имеет возможность брендировать интерфейс, настроить свои корп.цвета). Теперь для этого есть ещё один способ: готовое решение в одну строку, работающее на стороне браузера. JS имплементации подобного встречаются, и естественно они не столь изящны, как нативное решение.
Вообще у DisplayPort есть спецификация Hot Plug Detect, другое дело, что на уровне ОС это реализовано странно (отсоединив и присоединив один монитор это будет добавлением другого устройства с повторной полной инициализацией). Ну и, похоже, не все производители графических ускорителей поддерживают (хотя физически есть линия, изначально предназначенная для определения, присутствует ли устройство).
С VGA тоже были странности: обычное поведение — это устройство может быть подключено/отключено на горячую, но только если при загрузке BIOS присутствовало. Что, несомненно, является ещё каким архаизмом (как и сам VGA). Не вникал, но подозреваю, что связано с тем, что управление низкоуровневыми прерываниями в угоду совместимости не трогали с тех самых времён.
Есть 600 человек, если мы гарантированно спасаем 200 человек, то судьба остальных 400 нам неизвестна, в условиях задачи ничего об этом не сказано. Если нам удалось спасти 300, то утверждение о том, что 200 спасены является верным. Тут ИИ всё верно оценил, вопрос к постановке задачи.
В резервуар. А при появлении питания выкачивать обратно в систему.
Так и пусть сливает холодную. Если есть горячий теплоноситель в питающей магистрали, то пусть он и заполняет калорифер, попутно нагревая его. Можно сливать в резервуар с поплавковым клапаном, на случай, если температура в самой магистрали аварийно снизилась, но тогда уже речь про множественные отказы независимых систем, где вероятность совместного отказа крайне невысока.
Почему нельзя просто поставить клапан, который при снижении температуры носителя до 5-6 градусов автоматически осуществит аварийный сброс? Механический, если такой бывает или электромеханический с автономным питанием.
Почему бы стрелки не заменить на стик? Едва ли кто-то пользуется комбинациями, где задействовано более одной стрелки за раз. Как вариант ещё - это "качающийся" свитч: по поведению не отличается от остальных, так же прижимается, но без отклонения не имеет действия никакого (либо работает как ctrl т.к. это достаточно безобидная клавиша в случае ошибочного нажатия). При отклонении работает как соответствующая стрелка. Вроде идея на поверхности, однако почему-то до сих пор не встречал имплементацию.
И переместился в 1980?
Что если добавить к своей WiFi сети AP в режиме клиента (в качестве workaround-а) и подключиться к регистратору, не отправляя на него маршрут по умолчанию?
А вообще регистраторы — то ещё зло в плане интеграции с другими устройствами: лет 15 назад могли уже делать поддерживающие облако регистраторы, но, видимо, никому не надо. Из года в год характеристики не развиваются вовсе, меняется только дизайн корпуса и цена. А если с интеграцией в зеркало заднего вида, так и вовсе беда с качеством у всех, ни одного приличного производителя.
Но в случае с колонкой вообще кейс сложнее: несколько членов семьи подключаются к одному устройства с разных смартфонов, разные смартфоны при этом сами подключаются к разным колонкам, т.е. в любом случае человеку требуется подтвердить что и куда он собирается подключить.
Довольно простой случай: семья из 2 человек (условно Аарон и Сара), 2 автомобиля с мультимедиа системами (условно Audi и BMW). Аарону необходимо поехать в офис т.к. он забыл важный документ на столе, Сара решила воспользоваться свободным временем и поехать в супермаркет. Сегодня Аарон решил воспользоваться BMW, а Сара Audi (т.к. её попутно необходимо заправить). Оба выходят, погружаются в автомобили, мультимедиа стартуют и там и там, ищут bluetooth pair, находят, подключаются... не туда. Просто вчера Аарон катался на Audi, поэтому та система помнит последнее подключение от его смартфона, а не от её. А т.к. автомобили находятся на соседних парковочных местах, то и уровень сигнала от обоих устройств достаточно мощный.
Сумбурное что-то: WiFi — это L2, сеть — это L3, которая может быть развёрнута в т.ч. поверх WiFi в качестве канала. Создавать точку доступа на смартфоне и подключаться к ней объективом — сейчас бы для этого использовался какой-нибудь профиль Bluetooth. Ранее подобное подключение использовалось, например, для ELM адаптеров, но даже там было удобнее: сам адаптер служил точкой доступа (а единственное, что неудобно, так это то, что смартфоны умеют подключаться только к одной единственной сети, поэтому доступ к Интернет пропадал при использовании адаптера, поэтому уместнее использовать bluetooth, а серверной стороной служит смартфон, но раньше необходимые профили отсутствовали у продукции Apple, поэтому приходилось городить workaround-ы).
Лично я ожидал увидеть более одного производителя модулей. Эдакий отраслевой стандарт. Чтобы можно было ноутбук 5-8-летней давности модернизировать актуальным железом с актуальными интерфейсами. Плюс в качестве рабочей лошадки гибкость в выборе интерфейсов - довольно удобно, когда нужно в разных поездках подключаться к разным системам. Удобно, когда не сидишь где-то на технологической площадке телекома площадью один квадратный метр посреди птичьего гнезда из кабелей и адаптеров. Но модулей modbus, CAN или 1wire, напимер, я что-то не вижу в любом случае.
Как раз наоборот, чтобы избавить бекэндера от задачи поиска контрастных цветов и делегировании этого фронтендеру. Ранее, иногда, всё же требовалось, чтобы цветовые схемы динамически строились (когда кастомер сам имеет возможность брендировать интерфейс, настроить свои корп.цвета). Теперь для этого есть ещё один способ: готовое решение в одну строку, работающее на стороне браузера. JS имплементации подобного встречаются, и естественно они не столь изящны, как нативное решение.
Работали, в современных системах управления ДВС уже не используются.