Re: как демонизировать программу?
Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 11 Feb 2010 22:17:49 +0300:
>> Вику обычно не только читают через веб-интерфейс, но и пишут. И где-то
>> в этом процессе оно должно преобразовывать туда-сюда всяческую
>> викификацию. В ней-то собака и порылась. Либо викификация хреновая
>> (писать неудобно), как в cvstrac, либо движок сложный, либо и то, и
>> другое вместе.
AP> Мне html хватает в textarea. Кому не хватает - можно получить документ,
AP> отредактировать в любимом текстовом редакторе и закоммитить обратно.
Это - не вики.
>> AP> Насчет веб-интерфейса интереснее, но я полагаю, что для человека,
>> AP> написавшего свой _браузер_ не нужны значительные усилия для
>> AP> создания простого веб-интерфейса.
>>
>> _Простой_ веб-интерфейс, согласно unix way, следует делать _другими_
>> утилитами. Независимыми.
AP> В такой постановке - согласен. Но аналогично можно сказать, что
AP> текстовый редактор не должен уметь _редактировать_ текст - на то
AP> sed есть ;-)
Если я правильно ошибаюсь, в Plan9 с sam по сути так и сделано - есть
фронтэнд, который показывает морду, и бэкэнд, который редактирует. В
результате он гораздо прямее, чем все распространенные текстовые
редакторы, умеет редактировать удаленные файлы.
>> AP> Нужен кто-то, кто откроет сокет и поделится дескриптором.
>>
>> Это не "для обмена данных с сокетом", согласись?
AP> Задача обмена данными через сокет включает в себя открытие сокета и
AP> получение дескриптора. Вот ровно это и делают tcpserver и tcpclient
AP> - без зависимостей, без сотен килобайт "нафаршированного" бинаря...
А это ничего, что задача открытия сокета, которую может решать
tcpclient, вообще-то есть быть суть десяток совершенно шаблонных строчек
на C, а та, которую tcpserver - ну, два десятка?
А на tcl, соответственно, одна и три?
Ради этого громоздить бинарник, нафаршированный зависимостями от
динамической загрузки?
>> А утилита для открытия файлов, сокетов и прочей фигни называется socat.
>> Вот это - утилита, которая умеет ровно открыть и поделиться
>> дескриптором. Но умеет это хорошо. В отличие от.
AP> socat не утилита, а монстр чуть ли не с опенофис. И с пучком зависимостей:
AP> $ ldd `which socat`
AP> linux-gate.so.1 => (0xb777a000)
AP> libwrap.so.0 => /lib/libwrap.so.0 (0xb774b000)
AP> libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7747000)
AP> libreadline.so.5 => /lib/libreadline.so.5 (0xb7714000)
AP> libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb76cd000)
AP> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7586000)
AP> libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb742f000)
AP> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7418000)
AP> libncurses.so.5 => /lib/libncurses.so.5 (0xb73df000)
AP> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb73db000)
AP> libz.so.1 => /usr/lib/libz.so.1 (0xb73c6000)
AP> /lib/ld-linux.so.2 (0xb777b000)
AP> Из которых, к примеру, libwrap - довольно "мутное" изделие.А
AP> использование libreadline вызывает резонный вопрос - кем они себя
AP> считают? Утилитой или новым шеллом с прибамбасами? А еще сжатие
AP> встроено, криптация...
Ну, да. Потому что оно умеет открыть не только тупой TCP-сокет. И как
только тебе надо чуть больше, чем тупой TCP-сокет, твои tcpserver и
tcpclient немедленно начинают исключительно занимать место на диске. А
пользу приносить перестают. И все, что у тебя было завязано на их
использование, тебе приходится переписывать на что-то более вменяемое.
А libreadline там затем же, зачем и libssl. Только для разных типов
файловых дескрипторов. libssl - для SSL-сокета, а libreadline - для
терминала с юзером.
AP> Для примера:
AP> $ ldd `which tclsh8.5`
AP> linux-gate.so.1 => (0xb78a0000)
AP> libtcl8.5.so.0 => /usr/lib/libtcl8.5.so.0 (0xb7777000)
AP> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7773000)
AP> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7759000)
AP> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7733000)
AP> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75ec000)
AP> /lib/ld-linux.so.2 (0xb78a1000)
AP> Итого - названная вами "утилита" вдвое больше зависимостей имеет,
AP> нежели интерпретатор языка программирования общего назначения!
Ога, вот только этот интерпретатор без расширений нихрена не умеет
сидеть сервером на UNIX socket'е. А на TCP - умеет. Поэтому, чтобы
чуть-чуть расширить функциональность написанной на нем программы (а с
точки зрения собственно программирования после открытия и первоначальной
настройки разницы между UNIX и TCP сокетами - никакой), мне приходится
либо искать это расширение, либо радикально менять схему работы.
В случае сервера - именно что радикально. С клиентом обычно проще,
клиент с сокетом работает как с файлом. А вот listen сторонней утилитой
без "через жопу" (а вариант inetd/tcpserver/socat во многих случаях -
именно что через жопу) не организуешь.
--
Все гениальное просто.
Но со вкусом.
Кнышев.
Reply to: