А ведь была бы мотивация заиметь. Даёшь базовый экзамен по ПДД для пешеходов в 14 лет прям в рамках школьной программы, но с процессом приёмки как в ГИБДД и расширенный в 18, иначе сидишь дома и питаешься доставками + рандомные проверки прав на выход со двора у случайных пешеходов! И сдача практики на самокате, если хочешь! Ух, пойду в госдуму работать.
У меня каждый раз сердечко замирает, когда вижу как дети трюковым самокатом размахивать начинают, стоя перед светофором, потомушта СКУЧНО, даже когда я сам не за рулём. Это ж металлическая херота, которая весит достаточно чтобы при неловком движении обеспечить необходимость ремонта 2-3 кузовных деталей на каждую машину, в которую он прилетит и это я средне-хороший кейс привёл, где не затронуты стёкла и это не привело к потере управления и травмам. Реализации такого риска не видел, но кажется, что трясти с ребенка (связываться с его родителями) 15-350к рублей довольно ПРОТИВНЕНЬКО, не говоря уж о геморрое со страховыми, каско и отсутствием машины на период ремонта.
Раз двоякая функция, которая непонятно, то ли усиливает, то ли наоборот ухудшает безопасность автомобиля. Раньше при утере ключа (если смотреть на брелки, не на физические ключи) надо было ехать к дилеру, сейчас можно заблокировать телефон... но есть нюанс! Если вы живёте в экосистеме Apple достаточно давно и залезли туда с корнями: всё ок, берёте другое устройство и блокируете утерянный телефон. А вот если нет, то всё по паспорту и за несколько дней + не совсем ясно, будет ли работать в РФ:
Hidden text
> Без устройства Apple Вы не сможете сразу обновить свой номер телефона > > Самый простой и быстрый способ сбросить пароль — воспользоваться устройством c iOS или компьютером Mac. Если у Вас нет доступа к своим устройствам Apple, предоставьте другую информацию для подтверждения личности. > > Без устройства Apple подтверждение личности займет больше времени. Процесс обновления номера телефона может занять несколько дней или дольше. Служба поддержки Apple не может ускорить этот процесс. > > Мы понимаем, что такая задержка вызывает неудобства, но это время необходимо нам для обеспечения безопасности Вашей учетной записи и данных. Если Вы решите продолжить, то для подтверждения личности потребуется ответить на дополнительные вопросы.
Vehicle functions like radio and temperature controls are handled right from CarPlay.
Радио ладно, а вот температура уже двояко. С одной стороны, целиком переносить это в тачскрин - та ещё содомия, мне сейчас нравится на ощупь быстро найти нужную крутилку и повернуть её в нужную сторону. С другой стороны, если управлять этим голосом, можно вообще от руля не отрывать. Если управление голосом при этом будет работать в полном оффлайне - вообще супер. Но если забыл телефон дома, без него машина превратилась в полутыкву, а крутилочка была только сенсорная - это какая-то жесть.
Странно к слову, вроде на хабре читал про плюшки CarPlay 2.0, а на официальном сайте о них толком не слова. И когда читал ту статью - буквально думал ahh, sweet, men-made horror beyond my comprehension.
Ну, к слову от специализирующегося на python дистиллята в 8b размере я бы не отказался. Особенно если бы он внятно мог в русский язык и не скатывался в иероглифы, английски и мову.
Для части людей VPN-клиенты, поставляемые в комплекте с ОС, вписываются в модель угроз как доверенные. А вагон программ, вроде byedpi, не являются доверенными, проводить их аудит нет ни желания, ни ресурсов.
Мне удобно, проблемы будут если надо будет масштабироваться. А мне не надо, производительности хватает со стократным запасом. Это же умный дом, он в одном домохозяйстве крутится, у него полтора пользователя, которые предпочитают его вообще не трогать, пока работает. А учитывая то, что масштабирование/резервирование не требуется, можно извлекать выгоду из того, что состояние системы не распределено, персистентность не требуется, следовательно его можно тупо держать в памяти одного процесса и прекрасно обходиться без системы очередей (если не считать таким mqtt-брокер) и баз данных.
Единственная моя проблема (что нужно довести до ума) в том, что я не знаю как правильно организовать сборку проекта с фронтендом, который хочу распространять целиком через pypi (чтобы pip install, конфиг поправил, системд юнит включил и работает). Бандлить в питоний пакет собранный JS стрёмно, а как без сборки вебпаком использовать сторонние библиотеки (я использую jsonrpc, хотя мог бы болт забить и на это) - не знаю. Может надо дистрибьюцию на докер-образ переводить, но это кажется совсем уж шизой, ради 40 строк на JS и 600 на питоне (где 200 - тесты).
Не понимаю как из выбора монолитной архитектуры следует требование писать home assistant или лучше, к слову.
Где-то полтора года назад решил сделать самопальный примитивный умный дом. Это, наверное как todo-листы у людей, которые дорвались до mqtt. Плюс захотелось немного поделать что-то отличное от работы, без микросервисов и прочего, а реально компактный монолит (расписание, приём топиков из mqtt с блокировками расписания, сбор данных из внешнего мира, API + экспорт метрик + веб-интерфейс - всё в одном процессе, просто в разных asyncio.Task), пусть и на питоне. Сейчас что-то распухло до 50мб потребление памяти, но было бы время, мне кажется получилось бы до 25 ужаться. Где-то с 0.0.4 версии ушёл в хардкод и пока его не причешу, не заребейзю всё по человечески - не буду публиковать. Беда в том, что с этого момента прошло полгода, а фич я в свой проект добавил эгегей. Да и он особо никому не нужен, лол.
Концептуально - идея прикольная. Нет, серьёзно. Мне нравится.
Но я не совсем понимаю, как вы в реальной системе планируете привязывать SQL-запрос к какому-то идентификатору. Это надо структуру приложения менять - складировать куда-то SQL-запросы, пусть и генерируемые через ORM, чтобы потом это место как-то парсить. А если там query-builder какой-то, у которого итоговый SQL зависит от входных параметров? Из логов выхватывать? Но как их тогда с предыдущими версиями сопоставлять?
Число INNER JOIN тоже, конечно те ещё попугаи. Лучше, чем ничего, но и вредить может. К примеру было 3 отдельных последовательных SQL-запроса не под транзакцией. Объединили их под одну транзакцию? Стало хуже? Лучше? Объединили их с помощью JOIN - стало лучше или хуже? Как себя стал пул соединений чувствовать под нагрузкой от этого? А если таких запросов -> JOIN'ов 10? 20? Как себя ведёт планировщик постгри, переключившись на всякие генетические алгоритмы? Но вы вроде понимаете это и обозначили что JOIN - это просто пример.
Этот подход хорошо сработает для вторичных систем, по большей части состоящих из набора SQL-запросов. Или вы таки применяете его где-то ещё?:)
Откуда вы взяли IPFS в Mastodon?
А ведь была бы мотивация заиметь. Даёшь базовый экзамен по ПДД для пешеходов в 14 лет прям в рамках школьной программы, но с процессом приёмки как в ГИБДД и расширенный в 18, иначе сидишь дома и питаешься доставками + рандомные проверки прав на выход со двора у случайных пешеходов! И сдача практики на самокате, если хочешь! Ух, пойду в госдуму работать.
У меня каждый раз сердечко замирает, когда вижу как дети трюковым самокатом размахивать начинают, стоя перед светофором, потомушта СКУЧНО, даже когда я сам не за рулём. Это ж металлическая херота, которая весит достаточно чтобы при неловком движении обеспечить необходимость ремонта 2-3 кузовных деталей на каждую машину, в которую он прилетит и это я средне-хороший кейс привёл, где не затронуты стёкла и это не привело к потере управления и травмам. Реализации такого риска не видел, но кажется, что трясти с ребенка (связываться с его родителями) 15-350к рублей довольно ПРОТИВНЕНЬКО, не говоря уж о геморрое со страховыми, каско и отсутствием машины на период ремонта.
Почти Профессию Азимова переписали, только чуть на другой лад.
Это теперь дома придётся автопродление везде настраивать в своём самопальном CA для почти умного дома?:(
Я думал что ну хрен с ним, раз в год я пройдусь по всем своим железкам.
ollama run deepseek-r1:8b ?:)
Так я об этом и пишу (и сам скептически отношусь к этому, на самом деле).
Вот возьмём первоисточник:
https://www.apple.com/ios/carplay/
Раз двоякая функция, которая непонятно, то ли усиливает, то ли наоборот ухудшает безопасность автомобиля. Раньше при утере ключа (если смотреть на брелки, не на физические ключи) надо было ехать к дилеру, сейчас можно заблокировать телефон... но есть нюанс! Если вы живёте в экосистеме Apple достаточно давно и залезли туда с корнями: всё ок, берёте другое устройство и блокируете утерянный телефон. А вот если нет, то всё по паспорту и за несколько дней + не совсем ясно, будет ли работать в РФ:
Hidden text
> Без устройства Apple Вы не сможете сразу обновить свой номер телефона > > Самый простой и быстрый способ сбросить пароль — воспользоваться устройством c iOS или компьютером Mac. Если у Вас нет доступа к своим устройствам Apple, предоставьте другую информацию для подтверждения личности. > > Без устройства Apple подтверждение личности займет больше времени. Процесс обновления номера телефона может занять несколько дней или дольше. Служба поддержки Apple не может ускорить этот процесс. > > Мы понимаем, что такая задержка вызывает неудобства, но это время необходимо нам для обеспечения безопасности Вашей учетной записи и данных. Если Вы решите продолжить, то для подтверждения личности потребуется ответить на дополнительные вопросы.
Радио ладно, а вот температура уже двояко. С одной стороны, целиком переносить это в тачскрин - та ещё содомия, мне сейчас нравится на ощупь быстро найти нужную крутилку и повернуть её в нужную сторону. С другой стороны, если управлять этим голосом, можно вообще от руля не отрывать. Если управление голосом при этом будет работать в полном оффлайне - вообще супер. Но если забыл телефон дома, без него машина превратилась в полутыкву, а крутилочка была только сенсорная - это какая-то жесть.
Странно к слову, вроде на хабре читал про плюшки CarPlay 2.0, а на официальном сайте о них толком не слова. И когда читал ту статью - буквально думал ahh, sweet, men-made horror beyond my comprehension.
Вроде свежий CarPlay берёт на себя сильно больше, чем приложеньки с телефона. Может с этим связано.
Brother: запрещает сторонние картриджи вслед за HP и остальными.
HP: подержи моё пиво!
Что будет в 2030?
Интеграция со steamdeck?
Ну, к слову от специализирующегося на python дистиллята в 8b размере я бы не отказался. Особенно если бы он внятно мог в русский язык и не скатывался в иероглифы, английски и мову.
Интересно каково ассистенту в on-premise версии будет.
Он прямо сейчас так делает на iOS устройствах.
В случае с локальной ollama это ведь неактуально?
Для части людей VPN-клиенты, поставляемые в комплекте с ОС, вписываются в модель угроз как доверенные. А вагон программ, вроде byedpi, не являются доверенными, проводить их аудит нет ни желания, ни ресурсов.
Мне удобно, проблемы будут если надо будет масштабироваться. А мне не надо, производительности хватает со стократным запасом. Это же умный дом, он в одном домохозяйстве крутится, у него полтора пользователя, которые предпочитают его вообще не трогать, пока работает. А учитывая то, что масштабирование/резервирование не требуется, можно извлекать выгоду из того, что состояние системы не распределено, персистентность не требуется, следовательно его можно тупо держать в памяти одного процесса и прекрасно обходиться без системы очередей (если не считать таким mqtt-брокер) и баз данных.
Единственная моя проблема (что нужно довести до ума) в том, что я не знаю как правильно организовать сборку проекта с фронтендом, который хочу распространять целиком через pypi (чтобы pip install, конфиг поправил, системд юнит включил и работает). Бандлить в питоний пакет собранный JS стрёмно, а как без сборки вебпаком использовать сторонние библиотеки (я использую jsonrpc, хотя мог бы болт забить и на это) - не знаю. Может надо дистрибьюцию на докер-образ переводить, но это кажется совсем уж шизой, ради 40 строк на JS и 600 на питоне (где 200 - тесты).
Не понимаю как из выбора монолитной архитектуры следует требование писать home assistant или лучше, к слову.
Где-то полтора года назад решил сделать самопальный примитивный умный дом. Это, наверное как todo-листы у людей, которые дорвались до mqtt. Плюс захотелось немного поделать что-то отличное от работы, без микросервисов и прочего, а реально компактный монолит (расписание, приём топиков из mqtt с блокировками расписания, сбор данных из внешнего мира, API + экспорт метрик + веб-интерфейс - всё в одном процессе, просто в разных asyncio.Task), пусть и на питоне. Сейчас что-то распухло до 50мб потребление памяти, но было бы время, мне кажется получилось бы до 25 ужаться. Где-то с 0.0.4 версии ушёл в хардкод и пока его не причешу, не заребейзю всё по человечески - не буду публиковать. Беда в том, что с этого момента прошло полгода, а фич я в свой проект добавил эгегей. Да и он особо никому не нужен, лол.
И где он через 10 лет возьмёт сеньоров?
[ДАННЫЕ УДАЛЕНЫ]
Концептуально - идея прикольная. Нет, серьёзно. Мне нравится.
Но я не совсем понимаю, как вы в реальной системе планируете привязывать SQL-запрос к какому-то идентификатору. Это надо структуру приложения менять - складировать куда-то SQL-запросы, пусть и генерируемые через ORM, чтобы потом это место как-то парсить. А если там query-builder какой-то, у которого итоговый SQL зависит от входных параметров? Из логов выхватывать? Но как их тогда с предыдущими версиями сопоставлять?
Число INNER JOIN тоже, конечно те ещё попугаи. Лучше, чем ничего, но и вредить может. К примеру было 3 отдельных последовательных SQL-запроса не под транзакцией. Объединили их под одну транзакцию? Стало хуже? Лучше? Объединили их с помощью JOIN - стало лучше или хуже? Как себя стал пул соединений чувствовать под нагрузкой от этого? А если таких запросов -> JOIN'ов 10? 20? Как себя ведёт планировщик постгри, переключившись на всякие генетические алгоритмы? Но вы вроде понимаете это и обозначили что JOIN - это просто пример.
Этот подход хорошо сработает для вторичных систем, по большей части состоящих из набора SQL-запросов. Или вы таки применяете его где-то ещё?:)