А вообще есть смысл переходить на source generators и native aot в веб приложениях, которые запустили один раз и они неделями работают без перезапусков?
А чисто технически можно ли представить горелку в которой топливо будет подаваться под давлением через форсунку в сопло и уже там смешиваться с воздухом? Условный непосредственный впрыск, только для горелки, а не двигателя.
В нашей компании в точно такой же ситуации ни кто на Linux не переходит и проблем не испытывает. DevOps тоже не кричат, что всё плохо. С C# на бэке в случае веб сервисов вообще без разницы комбинация на чём разрабатывать/на чём запускать. Ну то есть чем мне вообще поможет переход на Linux для разработки?
Проще найти принтер с usb. Но вообще нужно ещё найти приложение, которое умеет в символьный вывод на принтеры. Хотя можно и самому за пару вечеров набросать приложение, которое умеет в esc/p, а потом ещё и запариться про шрифты, загруженные в принтер…
В теории все должно быть OK. Таким вроде контроллер питания занимается, а не сам SoC. Условно говоря подключение очков не должно отличаться от подключения любого другого устройства. А вот уже переводом в dp alt mode должен заниматься usb host контроллер, который в soc.
IMHO, вы обошли стороной довольно важную часть, которая доставляет много гемор при печати - системы выравнивания стола и всё связанное с этим. Voron tap, cartographer, то, что стоит внутри бамбука - мне кажется эта сторона развития принтеров также важна как и многоматериальная печать.
Первая версия шасси дичайше похожа на Tarmo4. По поводу поворотных кулаков, которые первыми сломались. Если взять пластик titi flex hard и напечатать со 100% заполнением, то получится жёсткая деталь, которую не сломать. У меня из этого пластика даже была пара шестерней двигатель-кардан - petg и abs плавились и стирались под нагрузкой, а этот TPU прекрасно жил. Ну и моё почтение с электроникой. Я пошёл по пути “купить несколько готовых компонентов и кататься”.
Все делалось на claude sonnet 4.x. Куда уж лучше. Ну и даже не знаю, как ответить на ваш тезис про “не умеет понимать”. Если AI в состоянии разобраться в том, что конкретно делает код и найти логическую ошибку, значит он в каком-то смысле понимает.
У меня странный опыт вайбкодинга с C++. Как будто бы AI на плюсовом коде быстро теряет логику происходящего. Я решал одну и ту же задачу( декодирование видео через v4l2 и отображение через DRM) на C#, C++ и Rust. В общем, нужно правильно всё инициализировать, а потом только жонглировать буферами. В C# самым сложным было заставить AI писать правильно p/invoke. Rust - без проблем. C++ - агент как будто бы забывал о структуре проекта, а при начале новой сессии ему было сложно понять код. Может AI плохо понимает конкретно плюсы. Может код на плюсах сам по себе труднопонятен.
Судя по коду скрипта и ссылкам на форум, то можно и gstreamer обойтись - камера в системе выглядит как обычное v4l2 устройство - веб камера. Если видеть только изображение, без тех данных, то можно и gstreamer обойтись. Но можно и допились python скрипт, чтобы он выводил через kms/drm. Тогда можно будет использовать lite версию RPI OS. Или вообще можно взять OpenHD и не париться - там и переключение между камерами есть, и, судя по коду есть поддержка Infiray, Infiray T2, Infiray P2 pro, Infiray X2, flir vue, flir boson
Вот тут https://github.com/buldo/SharpVideo Там понадергано всякого чтобы завести v4l2 декодирование и drm отображение видео на C#. То есть libdrm, и куча ioctl вызовов.
Ну вот, раньше у проекта было бесплатное веб приложение для конфигурации, а теперь его нет
Лямбда - это лямбда. Мне сложно называть это веб приложением
А вообще есть смысл переходить на source generators и native aot в веб приложениях, которые запустили один раз и они неделями работают без перезапусков?
А чисто технически можно ли представить горелку в которой топливо будет подаваться под давлением через форсунку в сопло и уже там смешиваться с воздухом? Условный непосредственный впрыск, только для горелки, а не двигателя.
В нашей компании в точно такой же ситуации ни кто на Linux не переходит и проблем не испытывает. DevOps тоже не кричат, что всё плохо. С C# на бэке в случае веб сервисов вообще без разницы комбинация на чём разрабатывать/на чём запускать. Ну то есть чем мне вообще поможет переход на Linux для разработки?
Мой LQ-630 стоил довольно дёшево б/у
Проще найти принтер с usb. Но вообще нужно ещё найти приложение, которое умеет в символьный вывод на принтеры. Хотя можно и самому за пару вечеров набросать приложение, которое умеет в esc/p, а потом ещё и запариться про шрифты, загруженные в принтер…
.NET для бэка и немного фронта. Рабочий комп на Windows. Деплой в линуксовый k8s. Не вижу проблем.
В теории все должно быть OK. Таким вроде контроллер питания занимается, а не сам SoC. Условно говоря подключение очков не должно отличаться от подключения любого другого устройства. А вот уже переводом в dp alt mode должен заниматься usb host контроллер, который в soc.
IMHO, вы обошли стороной довольно важную часть, которая доставляет много гемор при печати - системы выравнивания стола и всё связанное с этим. Voron tap, cartographer, то, что стоит внутри бамбука - мне кажется эта сторона развития принтеров также важна как и многоматериальная печать.
Первая версия шасси дичайше похожа на Tarmo4. По поводу поворотных кулаков, которые первыми сломались. Если взять пластик titi flex hard и напечатать со 100% заполнением, то получится жёсткая деталь, которую не сломать. У меня из этого пластика даже была пара шестерней двигатель-кардан - petg и abs плавились и стирались под нагрузкой, а этот TPU прекрасно жил. Ну и моё почтение с электроникой. Я пошёл по пути “купить несколько готовых компонентов и кататься”.
Все делалось на claude sonnet 4.x. Куда уж лучше. Ну и даже не знаю, как ответить на ваш тезис про “не умеет понимать”. Если AI в состоянии разобраться в том, что конкретно делает код и найти логическую ошибку, значит он в каком-то смысле понимает.
У меня странный опыт вайбкодинга с C++. Как будто бы AI на плюсовом коде быстро теряет логику происходящего. Я решал одну и ту же задачу( декодирование видео через v4l2 и отображение через DRM) на C#, C++ и Rust. В общем, нужно правильно всё инициализировать, а потом только жонглировать буферами. В C# самым сложным было заставить AI писать правильно p/invoke. Rust - без проблем. C++ - агент как будто бы забывал о структуре проекта, а при начале новой сессии ему было сложно понять код. Может AI плохо понимает конкретно плюсы. Может код на плюсах сам по себе труднопонятен.
Судя по коду скрипта и ссылкам на форум, то можно и gstreamer обойтись - камера в системе выглядит как обычное v4l2 устройство - веб камера. Если видеть только изображение, без тех данных, то можно и gstreamer обойтись. Но можно и допились python скрипт, чтобы он выводил через kms/drm. Тогда можно будет использовать lite версию RPI OS. Или вообще можно взять OpenHD и не париться - там и переключение между камерами есть, и, судя по коду есть поддержка Infiray, Infiray T2, Infiray P2 pro, Infiray X2, flir vue, flir boson
Почему просто не использовать gstreamer на rpi в выводом в kms/drm?
Прежде чем говорть про потребление малинки, стоит замерить его и сравнить с общим потреблением коптера. Вангую, что там будут жалкие проценты.
Нифига не подозрительный пост. Всей душой верю в гражданское применение.
Вы имеете ввиду то, что называется “папка Knox”?
Ну да, ну да, весь мир с этим как-то живёт, а вот C++ такой особенный, что только здесь будут проблемы
Вот здесь в csv, если мне не изменяет память. https://github.com/iplocate/ip-address-databases/tree/main/ip-to-asn
А почему просто не посмотреть на список AS в которых явно указан телеграм? Там значительно больше подсетей, чем указано в начале статьи
Вот тут https://github.com/buldo/SharpVideo
Там понадергано всякого чтобы завести v4l2 декодирование и drm отображение видео на C#. То есть libdrm, и куча ioctl вызовов.