ITF, Уф, про Вас как-то запамятовали :)
Вот, нашел интересный проект, может поможет, иначе можно немного проковыряться https://netboot.xyz/
В общем:
1) Монтируем CD и вытягиваем из него initrd
2) Смотрим, чем но упакован, подсовываем в меню
3) Пытаемся загрузить скондачка, скорее вего потерпим фейл, ибо в initrd не завезли драйверов всяких.
4) Распаковываем inird, правим скрипты и прочую хрень, добавляем драйверов - здесь все сильно зависит от дистрибутива и извращеной фантации аффтароф initrd и скриптов.
5) Повторяем до саккеса и оргазма с пункта 3.
rPman, ограничения только размером памяти целевого компа, и, временем загрузки такого толстого initrd.
Обычно initrd делают маленький, а rootfs монтируют по NFS
Просто ему (телефону) нехватает мощности, которую жрет 8 терабайтный SSD!
Думаю, на OTP устройства, там максимум 500 мА, чтобы не травмировать батарейку.
#, работает просто, добавляет скобочки если надо, и умеет внутри скобочек перемещать содержимое скобочек со скобочками.
Маст хев, если на лиспах программируете! Или просто программируете.
Так как я в емаксе, то вот кратенько https://m.youtube.com/watch?v=D6h5dFyyUX0
И длинненько для clojure https://m.youtube.com/watch?v=T1WBsI3gdDE
Кстати, для idea точно есть!
karalex, Вообще-то поток забирается. И да, сервер есть.
Есть модуль для nginx, который забирает rtsp и делает из него hls или rtmp - https://github.com/arut/nginx-rtmp-module
Но нужно компилировать.
karalex, просто настройте роутинг в сети. И если это просто tcp, что нужно смотреть в сессии rtsp, то просто пробросить любым socks5 прокси или haproxy ( или любым другим tcp/udp).
Вообще-то наверное хватит и просто socks5, но клиентов нужно настраивать на него.
Drno, Все просто, есть три основные модели работы с сокетами (остальное - варианты этих вариантов).
Первый и самый распространенный - основной процесс ожидает подключений клиентов, после подключения порождает свою копию через вызов fork (или его аналога). Первый процесс продолжает ждать следующих соединений клиентов, а порожденный процесс работает непостедственно с соединением клиента.
Плюсы - очень быстро программировать и отлаживать.
Минусы - много накладных расходов на порождение процессов, жрет лишнюю память в системе, относительно медленно работает.
Примеры - apache prefork.
Второй вариант аналогичен первому, но вместо порождения копии процесса, порождается функция-тред для работы с соединением клиента.
Плюсы - быстро программировать и отлаживать, все быстро работает.
Минусы - требует вдумчивого подхода к программированию, если что случается - падают все соединения разом, все же жрет ресурсы системы.
Примеры - многое современное сетевое ПО, в том числе и 3proxy
Третий вариант - единственный процесс обрабатывает и подключения и соединения с клиентскими сокетами, используя вызовы select/poll/epoll.
Плюсы - все безумно быстро работает, часто сочетают со вторым методом.
Минусы - требует очень вдумчивого подхода к программированию.
Примеры - nginx, haproxy
Drno, не, Вы неправильно поняли! 1 тред, это не одно ядро на коннект! Это программная модель обработки и работы с коннектами. Она расточительная, но менее сильно, чем порождать процесс на каждое новое соединение.
При этом, в большинстве случаев это оправдано с программной точки зрения - проще программировать.
Например сервер apache почти так и работает в версии prefork
Drno, То, что они сами пишут про 1 connect - 1 thread - это не может стоить дешево для любой системы, им бы хорошо в poll/epoll, но думается (мне, как программисту), это будет дорого стоить по разработке и переделке.
Таоке ощущение, что это виртуальный хостинг, и похоже, сам хостер иногда выключает машинку...