xx_RuBiCoN_xx, да, вечно вместо clear_ вспоминаю cancel_.
Не должно быть никаких "методом проб и ошибок". Надо чётко понимать, что делает код.
Принцип очень простой. В обычном обработчике вешаем следующий (register_next_step_handler) и дальше по цепочке следующие. Как только надо "выкинуть в главное меню", делаем clear_step_handler (в теории можно было бы сделать register_next_step_handler на самый главный обработчик, но это не очень хорошо, так как при clear освобождается занятая под состояние память, а тут нет).
Filipp Filippovich, 200-300 Wi-Fi берёт только с направленной антенной и скорее всего не самым убогим радиомодулем, а в этих мелких устройствах всё сделано для минимизации цены, размеров и энергопотребления. Так что скорее всего не очень это идея.
Читать man по openssl verify. Там, грубо, передаёшь сертификат и подписавший его сертификат, и он говорит ок или не ок. Просто прогоняешь от корневого до конечного всю цепочку так...
modcode, легальный API - да, платный. Зато всё белое и пушистое и с обязательствами, уже есть интеграции и в bitrix, и в jivosite, и в различных CRM/чатцентрах/чатботах. Чтобы сэкономить, народ рискует, играется нелегально с API для web.whatsapp.com, формально это запрещено, в реальности если не спамить и объёмы маленькие, то риски бана невелики. Но всё равно Особо Важный Номер в такой интеграции я бы не рекомендовал использовать. Лучше такой, что не страшно поменять.
Вообще-то файловая система - наиболее эффективное хранилище для таких задач.
1. Легко масштабируется, бэкапится.
2. Эффективно кэшируется операционной системой.
3. Множественный конкурентный доступ к разным файлам этой большой базы без каких-либо спецэффектов.
4. Риск повреждения данных минимальный. Разве что повреждается тот файл, который не успел записаться в момент ёк-ёк.
Архив это плохо - он по сути на каждую операцию изменения файла пересоздаётся заново. И если что - весь архив отлетает со всеми данными.
Минио на каждый файл создаёт каталог, внутри которого файл (возможно, зашифрованный) и json с метаданными - тут объектов файловой системы ещё больше, чем при обычном хранении файлов.
Виртуальный диск - это прям из пушки по воробъям. Проще и даже надёжнее тогда хранить файлы в sqlite, которая, к слову, может иметь формальный размер до 281 Тб (да, именно террабайт). Но база огромного размера это тоже не очень удобно.
Как правило, нормальная практика - хранить метаданные в sqlite (а может berkeleydb или ещё какой-нить локальной базе), сами файлы - в файлах. Как и написано в том вот ответе внизу. Сами имена файлов могут быть сколь угодно эзотерическими (какие-нить 16-ричные без расширения).
Иногда делают специфические решения под специфические задачи. Два примера приведу.
Первый пример - формат mbtiles. Придумали для тайловых данных (TMS) веб-карт, где много тайликов размера 256x256. Представляет из себя sqlite, в котором лежат эти файлы. Для чего используют? Во-первых, для обмена - много софта умеет собирать файлы в такой архивчик. Во-вторых, можно с помощью нарезания на таблицы и создания view оптимизировать хранение тайлов с одинаковым содержанием, что для читающего софта будет прозрачно. Но для приличного продакшн-решения mbtiles напрямую не используют, всё равно раскатывают в файлики.
Второй пример - программа SAS.Планета. Она позволяет качать в кэш и просматривать такие вот тайлики. Но там возникает проблема хранения миллионов довольно мелких файлов, что прилично напрягает файловую систему. Для оптимизации в ней разработали кастомный формат кэша sqlite, который всё же не одна суперпупербаза, а много 256x256 тайлов собираются в один sqlite-файл, которые уже раскладываются по каталогам. Количество файлов сокращается очень существенно, при этом они не превращаются в одну гигантскую базу с высоким риском повреждения и неудобством каких-либо действий с ней. Например, если мало места и кэш какой-то карты не нужен или не нужны какие-то конкретные масштабные уровни - то легко определить по именам каталогов, что именно удалить.
Всё это очень специфические случаи и для такого исхитрения есть реальные проблемы и конкретные задачи. А для обычного хранения файлов это чаще всего перебор. Вот надо подумать и решить - действительно ли конкретному десктопному приложению это всё необходимо, или всё же нет?
А зачем вообще ставить из rpm, оно не ставится другими путями, из архива, например?
В конце концов, можно поставить на el8 (хоть centos, хоть oracle linux) и затем скопировать /opt/oracle (или куда оно там ставится?) на другую машину и даже в другой каталог, указав его в ORACLE_HOME. Если SUSE не слишком исхитряется с общесистемными библиотеками, то должно прокатить (на Ubuntu прокатывает).
Если жёсткий диск не будет подключаться к макоси непосредственно, а только через sftp/samba/итд/итп, то совершенно неважно, какая там файловая система...
Там больше накладок с тем, что любая напроганная, установленная и настроенная хрень должна проходить сертификацию и аудит, ибо жёсткие требования к надёжности и высокая ответственность банка, в том числе перед регуляторами и законами. Поэтому любую модную технологию, вчера вечером появившуюся, там никто использовать не будет. А старые работающие решения используются до посинения.
GEDCOM в меру ограниченный формат, там далеко не все генеалогические сложности можно описать. Плюс он жуть какой древний. И поддержка фич софтом может плавать. И софт временами странные вещи думает о формате или пихает в комментарии какие-то свои данные.
Но даже GEDCOM надо как-то втянуть в свою программу и адекватно визуализировать. Что весьма тоже не такая простая задача.
Алан Гибизов, понятие брака тоже имеет смысл. Человек может состоять в браке несколько раз, состояние брака и другие опции (дата заключения/расторжения, причина расторжения) тоже бывают нужны.
А вот для ребёнка привязка к браку в принципе опциональна, но нормальна привязка к родителям. И то вылезет стопицот проблем. Бывают внебрачные дети. Бывают сироты или дети без установленного отца. Бывает практика усыновления - причём ребёнок может менять родителя...
И даже так, задача вычислять текущего отчима и даже предыдущих отчимов всё равно вызовет сложности.
Так что тут уже вопрос насколько сложные кейсы планируется покрывать этой моделью.
Не должно быть никаких "методом проб и ошибок". Надо чётко понимать, что делает код.
Принцип очень простой. В обычном обработчике вешаем следующий (register_next_step_handler) и дальше по цепочке следующие. Как только надо "выкинуть в главное меню", делаем clear_step_handler (в теории можно было бы сделать register_next_step_handler на самый главный обработчик, но это не очень хорошо, так как при clear освобождается занятая под состояние память, а тут нет).