Допустим, есть демон, который поймал SIGSEGV. Допустим, он сохранил backtrace в лог. Далее нам нужно прекратить выполнение процесса, и, желательно, перезапуститься. Просто прекратить выполнение - банально, хочется разобраться с перезапуском. fork() с последующим execve() должен работать. Но мне кажется, что fork() здесь не обязателен. Так ли это?

Конкретно - нужно мультикастом опрашивать сеть на наличие ONVIF-совместимых видеокамер, и вытягивать из них последующими запросами инфу, которая вся в XML и передаётся по протоколу, основанному на SOAP. Есть недопиленная самописная тулза на базе gSOAP, но она (и gSOAP тоже) далеко не фонтан. Очень обрадуюсь предложениям консольных утилит, высокоуровневых средств типа PHP- или Python- библиотек.

dbconfig-common используется в Debian как помощник в обновлении БД при обновлении версии софта. Есть ли альтернативный подход, кроме полностью ручного выполнения нужных действий? Как аналогичная задача решается (если решается) пакетами в других дистрах, например, gentoo?

Вопросом задался в связи с вот чем. Дополню: по факту при обновлении нашего пакета на своём сервере один юзер выбрал дефолтное «не обновлять», в связи с чем у него в дальнейшем вылезли проблемы, хотелось бы не допустить повторения подобного. Вопросы debconf-а в самом деле выглядят страшновато, даже для меня, гентушника с 5-летним стажем, поэтому хотелось бы их убрать. Если кто может просветить конкретно по данной проблеме - буду благодарен.

Необходима поддержка MySQL и других популярных движков (SQLite, PostgreSQL etc.). Пока что приложение использует только MySQL, но необходима поддержка других альтернатив на перспективу.

Либа должна быть FOSS.

Привет всем. Года три как пользуюсь VPS на HostVirtual(vr.org) за $40/mo. Висит на ней в принципе много чего (apache с несколькими сайтами, mysql, exim, mailman, prosody, irssi...), но в принципе ничего высоконагруженного не должно быть, да и

load average: 0.00, 0.02, 0.05

Неладное стал замечать в последние полгода. Проблема в том, что иногда интерактивное приложение в ssh-сессии (vim, mysql, mcabber, irssi, да и сам bash) жёстко тупит. При этом проблема явно не в передаче данных по TCP, так как, например, нажатия клавиатуры отображаются, а действие приложения (например, отрисовка приглашения комстроки) тормозит.

Это они своё железо перегрузили виртуалками? Или какие-то идиоты майнят коины на VPS? Или искать у себя вирус, скрывающийся от ps axfu?

Сейчас пользуюсь gqview по старой привычке, но многое в нём не нравится. Нужно:

• Избавиться от неудобства gqview, который при клике на картинке переходит к отображению следующей картинки в каталоге - нужен режим работы сугубо с одним изображением.
• Возможность просматривать картинку в full screen, двигая видимую область drag'n'drop-ом (есть в gqview) и выделяя регион для просмотра выделением прямоугольника (нету в gqview).
• Zoom in/out, fit in window, 1:1 scale по простым хоткеям.
• Минимум траты оконного пространства на элементы управления.

Око видит, зуб неймёт.

Тысячи людей в СНГ и по всему миру заинтересованы в использовании LCD-панелей с LVDS-входом, с HDMI-выходом. Для некоторых хотелок реально можно использовать только такие панели - где вы видите в продаже компактные и качественные мониторы, скажем, на 13-15 дюймов?

Решение по факту предлагают только китайцы (см. aliexpress), оно избыточно, непомерно большое по габаритам, не имеет документации и информационной поддержки покупателей. Компактный переходник по факту недоступен в продаже, и, увы, также не имеет документации и производитель не готов осветить все вопросы настройки и использования устройства.

Поверхностное изучение вопроса позволило мне выяснить, что для такого преобразования используется одно-единственное семейство чипов от TI, ещё две хреновины на платке, полагаю - управляющий контроллер и память настроек.

Я прошу вас высказаться, каких, по вашим оценкам, масштабов затрат требует производство решения этой проблемы, и кто может этим заинтересоваться. Я не коммерсант и не производственник, я совсем из другой отрасли, но я очень хочу обратить на эту тему внимание тех, кто в силах её реализовать. Но на примете у меня также нет таких людей.

Такой же вопрос задал на форуме DIHALTа. Можете отвечать там, где считаете это более целесообразным.

Поделитесь, пожалуйста, инфой, какие решения вы используете, или стали бы использовать, если бы вам потребовалось представить широкой публике доступ к видео с IP-камеры (или нескольких камер) на постоянной основе и в реальном времени.

Собственный сервис с стриминговым софтом?

Сторонний коммерческий сервис? Этот случай особенно интересен. Будьте добры, расскажите, кем вы пользуетесь, сколько платите за это, и что вы за это получаете (какие лимиты, какие возможности).

Если пока что ничем не пользуетесь, то какой вариант вы бы стали разрабатывать?

Заранее благодарю за любую информацию.

Таковые вообще там проводятся?

Со зрением у меня пока всё в порядке, да и не считаю, что производительность глаз уже стала bottleneck для меня (им чаще является способность мыслить), однако иногда приходится много читать, после чего серьёзно болят глаза. Слабовидящих и незрячих родственников и знакомых тоже нет. Но я решил на время отложить исконно русский поуизм к окружающим, и подумать, а не нужен ли нормальный брайлевский дисплей?

Нормальный, в моём неквалифицированном понимании - это 80х25 знаков, например. В интернете я увидел коммерческий продукт только с одной строкой, и какой-то прототип с четырьмя строками. И совместимый со стандартным виртуальным терминалом. Понятно, заморачиваться передачей цвета не выйдет, хотя не-чёрный фон можно как-нибудь передать, например, поднятием самой площадки знакоместа, или удвоенным поднятием пупырышков.

Проблемой будет также передать всё буйство UTF-8. Пока я понял только, что 6-пин не подойдёт в принципе. Слишком мало комбинаций. А вот с 8-пин можно поразбираться. Но, конечно, тут решающее слово за практиками - нуждающимися пользователями, и теми, кому приходится с таковыми общаться/работать.

ЗЫ Также с удовольствием послушал бы об альтернативах - нейроинтерфейсах каких-нибудь. Речевые интерфейсы не канают, ибо в консоли наша сила.

Некоторое время пытаюсь применять git для отслеживания изменений в файлах на системе (VPS на Gentoo).

Возможности, ради которых я пошёл на такой изврат:

• git status, git diff удобно покажут, что я изменил в процессе редактирования настроек с момента создания предыдущей контрольной точки (коммита) - контроллируем отсутствие случайных изменений;
• git status покажет, какие именно файлы изменены в процессе emerge, dispatch-conf;
• тот же git status покажет, какие спонтанные изменения происходят в системе помимо прямых действий администратора;
• шаги изменения настроек или установки новых пакетов можно и нужно аннотировать (в commit message);
• удобно найти в истории и просмотреть содержание конкретного изменения - может помочь вспомнить при настройке других систем, что именно следует менять, и в какой последовательности настраивать и устанавливать пакеты;
• если коммитить аккуратно и гранулированно, то лог коммитов является готовым руководством по совершению аналогичных инсталляций.
• можно легко откатываться на последнюю или предыдущие контрольные точки через git reset --hard.

Но, увы, есть серьёзные недостатки:

• при появлении новых файлов нужно делать «git add». Если это результаты emerge - то как минимум «git add .» (cwd=/), плюс нюансы (см. ниже);
• некоторые файлы и каталоги вводить под отслеживание git-ом нецелесообразно, в результате имеем большой файл .gitignore, который по ходу эксплуатации необходимо поддерживать в актуальном состоянии, а также удалять ранее попавшие файлы подобного рода из старых коммитов с помощью git-filter-branch (с которым вообще мозг сломаешь, тем более, что нужен он редко);
• в силу того, что определённые файлы, находящиеся в системе, мы в git не храним, а также потому, что git не хранит инфу о владельце, и, возможно, ещё по массе причин, результирующий репозиторий НЕ ЯВЛЯЕТСЯ ПОЛНОЦЕННЫМ БЭКАПОМ, при этом
• занимаемый объём под .git ощутим.

Итак - есть ли системы бэкапа, обладающие плюсами описанного способа, и не имеющие данных минусов? Иными словами, с возможностями:

• аннотирования инкрементальных бекапов (git commit -m);
• запуска создания инкрементального бэкапа командой с бэкапируемой системы, с заданием аннтоации;
• пометить инкрементальный бэкап как вечно хранимый, а также с вечным хранением всех аннотаций (для получения «записок склерозника»);
• увидеть содержимое инкрементального бэкапа, примерно в виде diff;
• аналогичными git status/git diff, доступными для запуска на бэкапируемой машине.

P. S. С серьёзными решениями для бэкапа не знаком, данные на практике резервирую дублированием с помощью rsync или git.

Появилась мысль использовать планшет + клавиатуру как замену рабочего ноута/нетбука. Конпелять и настраивать умею и люблю, так что сложности установки не пугают. Прошу высказаться - возможен ли в сегодняшних реалиях такой подход, и какие модели стоит попробовать.

Работать требуется с непрожорливыми нативными Linux-приложениями (vim, ssh, gcc...) и даже в консольном режиме, из прожорливых разве что браузер.

В свете того, что основная масса планшетов на ARM, скайп будет идти лесом, ну что ж поделаешь, не критично.

Важно иметь как можно большее время автономной работы. Недурно было бы хотя бы 12 часов при небольшой нагрузке, и более суток при простое. Вроде бы, для планшетов сегодня это не проблема, а вот у нетбуков и близко такого нет.

Соответственно будет использоваться отдельная клавиатура (bluetooth или проводное подключение - пока не принципиально). Так что жду рекомендаций о моделях в наборе с чехлом и клавой, или об удачных «аксессуарах» в виде чехла и клавы, подходящих к множеству моделей.

Экран чем больше, тем лучше.

Нужен встроенный 3G модем, WiFi, Bluetooth.

Нужен хостовый USB-порт.

Практически нужен bootable microSD слот, чтобы использовать свою ОС без перепрошивания. Опыта такового пока нет, неохота сразу рисковать.

Приятным бонусом будет UART, доступный где-то из глубины его тушки.

Нужно для удобной работы с образами HDD, флешек и т. п. без использования отдельного физического носителя. От этого фиктивного блочного устройства требуется:

• возможность редактировать его «таблицу разделов» стандартными средствами
• наличие в /dev/ файлов всех разделов, возможность монтировать их в свою очередь и работать с ними.