Re: как демонизировать программу?
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 12 Feb 2010 15:37:00 +0300:
>> AP> Задача обмена данными через сокет включает в себя открытие сокета и
>> AP> получение дескриптора. Вот ровно это и делают tcpserver и tcpclient
>> AP> - без зависимостей, без сотен килобайт "нафаршированного" бинаря...
>>
>> А это ничего, что задача открытия сокета, которую может решать
>> tcpclient, вообще-то есть быть суть десяток совершенно шаблонных строчек
>> на C, а та, которую tcpserver - ну, два десятка?
>>
>> А на tcl, соответственно, одна и три?
>>
>> Ради этого громоздить бинарник, нафаршированный зависимостями от
>> динамической загрузки?
AP> Возьмите статическую сборку, с dietlib.
Ога, и пересобирайте каждый раз, как кто-нибудь обнаружит уязвимость в
оной. Кстати, резолвер-то в нее встроен, или сколько библиотек придется
собирать статически и отслеживать их секьюрити апдейты?
>> AP> socat не утилита, а монстр чуть ли не с опенофис. И с пучком зависимостей:
>> Ну, да. Потому что оно умеет открыть не только тупой TCP-сокет. И как
>> только тебе надо чуть больше, чем тупой TCP-сокет, твои tcpserver и
>> tcpclient немедленно начинают исключительно занимать место на диске. А
>> пользу приносить перестают. И все, что у тебя было завязано на их
>> использование, тебе приходится переписывать на что-то более вменяемое.
AP> А ничего, что tcpserver так и называется потому, что с tcp
AP> работает? Надо вам другой сокет - возьмите другую утилиту. Или вы
AP> за виндовый подход, когда каждая программа тащит в себе как можно
AP> больше всего? Тогда не надо про юникс-вей говорить в этом
AP> контексте, если требуете, чтобы утилита tcp... работала с udp,
AP> юникс-сокетами, служила эмулятором терминала и проч.
Не, я не требую. Утилита, которая так работает, называется socat. Я,
собственно, ее и беру...
>> А libreadline там затем же, зачем и libssl. Только для разных типов
>> файловых дескрипторов. libssl - для SSL-сокета, а libreadline - для
>> терминала с юзером.
AP> С каких это пор в линуксе проблемы с терминалами, так что
AP> приходится эту функциональность в socat пихать? Натуральный монстр,
AP> по идеологии виндоус.
Не "терминала", а "терминала с юзером". Ты, типа, не в курсе, что
возможность нормального редактирования вводимой строки юзеру
предоставляет ни разу не терминал?
>> Ога, вот только этот интерпретатор без расширений нихрена не умеет
>> сидеть сервером на UNIX socket'е. А на TCP - умеет. Поэтому, чтобы
>> чуть-чуть расширить функциональность написанной на нем программы (а с
>> точки зрения собственно программирования после открытия и первоначальной
>> настройки разницы между UNIX и TCP сокетами - никакой), мне приходится
>> либо искать это расширение, либо радикально менять схему работы.
AP> Фактически unix-сокеты давно уже в состоянии deprecated, но в этом
AP> явно не тикль виноват. А учитывая тенденции по монтированию
AP> удаленных ФС по http-based протоколам, и вовсе. Судя по DBUS и
AP> проч., юникс-сокеты скоро и с серверов пропадут. Я не говорю, что
AP> это именно хорошо, но так уж есть.
Не "фактически", а "у криворуких десктопных программистов". Нормальные
же серверные программы очень нескоро перейдут от сокетов, спокойно
тянущих весьма нехилую нагрузку, к дбасу, который десятка юзеров не
выдерживает.
--
/итд/почтопосылалка.нстрк (c)
Reply to: