> Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.
Потому что вместо наема людей, которые решают практические задачи, компании нанимают гениальных сортирователей списков. В некоторых случаях алгоритм-мен оказывается квалифицированным, но в остальных… Нет ничего хуже кода, написанного абстрактным олимпиадником.
Аппаратное сжатие VP9 не так распространено как H264. Проблема лицензирования преувеличена, потому что оно не касается именно нашей сферы использования.
Вы говорите про серверную часть, но она тут не играет никакой роли. В Pi-KVM свой собственный VNC-сервер, написанный мною с нуля. И, кажется, довольно быстрый)
Я рекомендую TigerVNC именно в качестве клиента, потому что он поддерживает наибольшее количество расширений протокола (типа передачи кейсимов клавиш, авторизации по юзеру-паролю и прочего). Кроме того, разрабы TigerVNC оказались более открытыми к диалогу по поводу внедрения H.264. Я написал серверную часть, составил спецификацию, мы обсудили ее и начали процесс внедрения в клиентскую часть.
Разработчик TightVNC не поддержал нашу инициативу. Хотя, как мне кажется, у него уже не останется выбора, потому что формат описан, принят в IANA и сейчас разработчик одного из мобильных VNC-клиентов тоже занялся его реализацией, так что клиента уже будет как минимум 2.
PS: Тут я, конечно, чувствую определенную гордость, так как мне удалось сдвинуть развитие VNC с мертвой точки в плане внедрения дифференциального кодирования :)
Не проблема. Там микросервисная архитектура. VNC реализован как прокси, который просто разворачивает протокол в вызовы HTTP API. Но, понятно, это писать надо)
Не исключено. Там могут быть другие внутренности. В любом случае, других способов пока нет. Для преобразования VGA сигнала в удобоваримую для пая форму нужен АЦП, а они либо плохие, либо дорогие.
Это уже сейчас kvm-over-vnc, а с h264 это будет kvmd-over-vnc-не-жрущий-трафик :) Правда, RealVNC с ним не заведется, потому что RealVNC на самом деле не совсем VNC, он поддерживает только базовую авторизацию и видео без сжатия, а с открытыми общепринятыми стандартами не работает, только со своими проприетарными. Так что вам понадобится TigerVNC под винду.
С зерошкой так не получится. Она так медленно грузится, что USB вылетает в таймауте при соединении.
Кстати, если выдастся возможность попробовать мое поделие, то сможете использовать VNC вместо браузера. Сейчас совместно с разработчиками TigerVNC я разрабатываю первую в мире открытую реализацию H.264-сжатия для VNC, и скоро она поедет в релиз. Протокол уже зарегистрировали в IANA, патчи готовы и ждут мержа.
Вообще возможно, но на практике лучше накатить готовую ось — например, для эмуляции диска требуется отдельный раздел на sd-карте, который, как и корень, содержится в ридонли, пока явно не понадобится. Ось содержит пакетный реп (все обновляется естественным путем) и множество специфичных настроек — следствие большого количества фич.
Привет. Я автор проекта, который описан в статье) Штука, на которую вы ссылаетесь, появилась совсем недавно, имеет меньше фичей и использует мой софт — ustreamer — который я написал с нуля для передачи видео. Так что, возможно, вам стоит ознакомиться именно с Pi-KVM как с первоисточником этой технологии)
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.
Я рекомендую TigerVNC именно в качестве клиента, потому что он поддерживает наибольшее количество расширений протокола (типа передачи кейсимов клавиш, авторизации по юзеру-паролю и прочего). Кроме того, разрабы TigerVNC оказались более открытыми к диалогу по поводу внедрения H.264. Я написал серверную часть, составил спецификацию, мы обсудили ее и начали процесс внедрения в клиентскую часть.
Разработчик TightVNC не поддержал нашу инициативу. Хотя, как мне кажется, у него уже не останется выбора, потому что формат описан, принят в IANA и сейчас разработчик одного из мобильных VNC-клиентов тоже занялся его реализацией, так что клиента уже будет как минимум 2.
PS: Тут я, конечно, чувствую определенную гордость, так как мне удалось сдвинуть развитие VNC с мертвой точки в плане внедрения дифференциального кодирования :)
С зерошкой так не получится. Она так медленно грузится, что USB вылетает в таймауте при соединении.