Теперь в системд будет свой mount - systemd-mount

В случае обработки сотен тысяч текстовых файлов конечно же. Но, это по производительности. А по жручести памяти всё произойдёт гораздо быстрее. Тем более что часто проще дампить кучу текста не по разным текстовым файлам, а в один. Так получаются текстовые файлы на много гигабайт (в KOI8-R). А если ещё начать работать с несколькими параллельно...

На моем древнем i3 обе программы занимают примерно одинаковое время. Мб просто не стоит обрабатывать сотни твсяч текстовых файлов на RPI?

P.S. И это время не 52 секунды:

$ cat test1.data | time ./test1
60
./test1  0.00s user 0.00s system 45% cpu 0.002 total
$ cat test2.data | time ./test2
7
./test2  0.00s user 0.00s system 0% cpu 0.002 total

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

А от «важных свойств» скоро вообще ничего не останется.

От каких свойств? Давайте конкретнее! Вы о том, что можно делать так:
cat old.conf | grep -v bla-bla-bla > new.conf
Так можно и с реестром сделать при наличии удобного интерфейса к нему.
Более того, если бы стандартные утилиты выдавали не просто текст, а некий унифицированный формат, то манипулировать данными было бы гораздо проще и удобнее.

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

Мой друг-очкарик запросто сидит в иксах с огромными шрефтами. Алсо смотреть интернет в lynx вместо браузера довольно убого, как мне кажется. Не 80-е года жеж.

А мне очки для близи запрещены офтальмологами. Да у меня близорукость и не столько от глазных яблок сколько от нервной системы. Воспаления глазных нервов и всё такое прочее. В итоге изображение засвечено ложными артефактами, и очки тут помогают лишь самую малость.

Блин, только что понял, что собиралось с -O2. Перемерял:

test1.c:

#include <stdio.h>
#include <string.h>

int main(){
        char buf[120];
        long long i;
        int x;
        fgets(buf, 120, stdin);
        for (i = 0; i < 10000000000; i++) x = strlen(buf);
        printf("%d\n", x);
        return 0;
}

test1.data:

P.S. þÔÏ ÚÎÁÞÉÔ <<ÔÏÒÍÏÚÑÔ>>? óÓÙÌËÉ ÎÁ ÂÅÎÞÍÁÒËÉ × ÓÔÕÄÉÀ.

test2.c:

#include <stdio.h>
#include <string.h>
#include <wchar.h>

int main(){
        wchar_t buf[120];
        long i;
        int x;
        fgetws(buf, 120, stdin);
        for (i = 0; i < 10000000000; i++) x = wcslen(buf);
        printf("%d\n", x);
        return 0;
}

test2.data:

P.S. Что значит <<тормозят>>? Ссылки на бенчмарки в студию.

Результаты:

$ cat test1.data | time ./test1 
60
./test1  48.63s user 0.01s system 99% cpu 48.645 total
$ cat test2.data | time ./test2 
7
./test2  45.37s user 0.00s system 99% cpu 45.372 total

P.S. Widecharacter тест закончился быстрее. Ололо.

Причем тут современность GNU/Linux
Консольный? Ну поставь LibreOffceKit, увидишь срач
То, что ты пользуешься минимальным набором софта не означает, что срача в /etc нету у других пользователей, которые пользуются популярным софтом, с которым работать удобно

Не знаю, что там с ядром, но вот про память - странная претенизя
Память нынче копеечная, и экономить смысла нету
Я готов потратить лишние 2 гигабайта ради повышения продуктивности

Ну, man'ы описывают не только опции конфигурации.

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

Может я и ошибаюсь, но Юникод также и включает ASCII, и занимают ASCII символы столько же, сколько и без юникода
Что-то вроде режима совместимости

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

Сначала придумай концепт, потом наложили его на реальность, попробуй перетащить десяток программ (не патчами, а на бумажке), попробуй обновить для этого документацию. Если получится годно - приходи исчо :)

А что хорошего?

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

А для пользователей есть dconf-editor

В бинарности. Конфиги должны быть в человекочитаемом plaintext'е.

А кто говорит об обязательной бинарности.
«реестр» может быть структурой каталогов с JSON (например, я не настаиваю и надо подумать).

А что плохого в бинарности? Для чтения и редактирования текстового конфига тоже нужен софт (grep, cat, sed, редактор, ...). Что страшного в том, что для реестра нужен будет софт? Будет какой-нибудь reg-grep, что плохого?

А ещё «реестр» ведь отлично ложится на файловую систему и его можно править через FUSE:
ls /registry/packages/calculator
fontFamily:str fontSize:int showResultsHistory:bool

Ну или правила для logrotate.

А уж тут-то чего не пихается? Правила там простые же.

Ну вот как будет выглядит вот такое правило в key-value:

/var/log/auth.log
/var/log/cron.log
/var/log/daemon.log
/var/log/kern.log
/var/log/lpr.log
/var/log/mail.log
/var/log/news.log
/var/log/user.log
/var/log/debug.log
/var/log/messages
{
	rotate 4
	weekly
	missingok
	notifempty
	compress
	delaycompress
	sharedscripts
	postrotate
		test -r /run/rsyslogd.pid && kill -HUP $(cat /run/rsyslogd.pid) &>/dev/null
	endscript
}

А для пользователей есть dconf-editor

Мы вроде это уже проходили: dconf в итоге становится ещё более жуткой помойкой, чем /etc.

А ещё «реестр» ведь отлично ложится на файловую систему и его можно править через FUSE:
ls /registry/packages/calculator fontFamily:str fontSize:int showResultsHistory:bool

Т.е. реестр превращается в /etc?

Ну вот как будет выглядит вот такое правило в key-value:

Также и будет (тут я указываю типы, естественно, писать их руками не надо).

paths:str = "/var/log/auth.log:/var/log/cron.log:...."
archivedLogs:int = 4
period:str = "weekly"   *
ignoreMissing:bool = true
skipEmpty:bool = true
compress:bool = true
delayCompress:bool = true
sharedScripts:bool = true
postRotate:str = "bla-bla-bla"

Это проблемы софта, а не ОС. А проблемы софта не означают что нужно убивать ОС. ОС со всеми фичами нужно беречь и лелеять.

Наверное не самый удачны пример сложного конфига. Этот-то какраз очень простой.

Да. Этот очень простой. А теперь положа руку на сердце взгляни на оба варианта, и скажи мне, какой проще читать и редактоировать.

Не везде можно легко и просто нарастить оперативку. На тех же микрокомпьютерах так нельзя. Да и зачем если можно бережнее к ней относиться и тогда её хватит?

Где православный аналог systemd от RMS?

https://www.gnu.org/software/shepherd/

Не везде можно легко и просто нарастить оперативку. На тех же микрокомпьютерах так нельзя. Да и зачем если можно бережнее к ней относиться и тогда её хватит?

Затем, что целесообразнее доставить памяти и использовать юникод. Он сильно упростил жизнь.

И все это ради парент маунта? Один юзкейс на миллион.

Только UTF-8 и только касательно ASCII. Кириллица уже жрёт по 2 байта на символ и в UTF-8. В UTF-16 даже каждый ASCII символ по 2 байта. А в UTF-32 даже каждый ASCII символ по 4 байта. wchar_t в Linux'е внедрён так чтобы работать с UTF-32.

Т.е. реестр превращается в /etc?

=)

Для меня реестр это унификация. Если поклеить ещё и со справкой (+ схемами/шаблонами), то и большое удобство. Это в первую очередь. Способ доступа уже во вторую. Способов может быть несколько. Я описал один из них, который удобен для работы со старыми утилитами и для скриптовой обработки.
Для пользователя может быть удобный редактор, со справкой, автопроверкой и т.п.

И нет, древовидность не ставит знака равенства между реестром и /etc.

Плохое в ломании стандартов. Есть стандарты на текст. Вот им и должны соответствовать конфиги.

У тебя спектрум с 16К памяти, что ты вес каждого символа считаешь? Кого вообще должен волновать объем текста на диске, если по сравнению с остальными данными он ничтожен?

Кому как. Мне и с KOI8-R хорошо.

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

У тебя спектрум с 16К памяти, что ты вес каждого символа считаешь? Кого вообще должен волновать объем текста на диске, если по сравнению с остальными данными он ничтожен?

Чуваку просто доставляет оптимизировать. Такое случается.

А теперь положа руку на сердце взгляни на оба варианта, и скажи мне, какой проще читать и редактоировать.

Читать совершенно одинаково. Я же написал что должно храниться, а не как это должно выглядеть.
А выглядеть это будет практически одинаково, как несколько строчек текста.

Удобство редактирования зависит от редактора. И тут, при наличии схемы конфигурации, вариант с реестром даже значительно выиграет: автодополнение названия параметров, подстановка значений по умолчанию, т.д.

Как это будет (при наличии схемы конфигурации):
Открыл/создал пустую ветку. Поставил курсор на первую строку. Пусть у нас часть редактора, где отображается key-value наполнение ветки выглядит построчно. Переход от названия параметра к значению по Tab и Enter, после ввода значения Enter переводит курсор с созданию следующего параметра.

pa[Enter](сработало автодописание, начался ввод значения) бла-бла-бла[Enter](переход к новому параметру)
arc[Enter](сработало автодописание, начался ввод значения) 4[Enter](переход к новому параметру)
per[Enter](сработало автодописание, выбор параметра из списка) стрелочки вверх/вниз, выбор нужного[Enter](переход к новому параметру)

Я думаю, что смысл понятен, всё переписывать я не буду. Получается быстрее и удобнее, чем с текстовым вариантом. Плюс исключается возможность опечатки. А хороший редактор может и пути к файлам дополнять. Кстати, схема может быть чуть более продуманной и paths в ней будет не строкой, а специальным типом files. Тогда редактор будет дописывать имена файлов, предупреждать, если файла такого нету. Думаю, что для любого уважающего себя софта наличие схемы будет обязательным. Кроме того, на основе неё можно будет генерировать часть кода самого приложения, которая читает конфигурацию.

Если схемы нету, то будет чуть скучнее, без автодополнения.

ИТОГ: хороший и продуманный реестр уделывает данный конфиг.

Давай еще примеров!

Плохое в ломании стандартов. Есть стандарты на текст. Вот им и должны соответствовать конфиги.

Всё меняется, форматы конфигов тоже меняются, т.к. софт развивается. Я не говорю, что завтра все к этому перейдут. Но, надо к этому стремится.

Ты знаешь, примерно подобные мысли посещали Кита Пакарда, когда он делал xml'ый конфиг fontconfig. В итоге редактор никто не написал, и все до сих пор правят _ЭТО_ руками. Потом подобные мысли посещали авторов Bluez, когда они выкинули все файлы конфигурации, грохнули pand и сказали, что нужно теперь делать через dbus и пишите клиента. Клиента, который полностью и хорошо реализует весь bt стек, так никто и не написал. Чуешь, к чему я клоню?

Кому как. Мне и с KOI8-R хорошо.

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

Я думаю, что смысл понятен, всё переписывать я не буду. Получается быстрее и удобнее, чем с текстовым вариантом. Плюс исключается возможность опечатки. А хороший редактор может и пути к файлам дополнять. Кстати, схема может быть чуть более продуманной и paths в ней будет не строкой, а специальным типом files. Тогда редактор будет дописывать имена файлов, предупреждать, если файла такого нету. Думаю, что для любого уважающего себя софта наличие схемы будет обязательным. Кроме того, на основе неё можно будет генерировать часть кода самого приложения, которая читает конфигурацию.

Будет о чем говорить, когда ты напишешь PoC такого редактора. Пока что у нас есть пример regedit/dconf, которые та ещё параша.

Чуешь, к чему я клоню?

Ога. Теперь представь, что нормальный текстовый редактор никто не написал и правь свои конфиги через ed или cat+grep+awk+sed.

Ога. Теперь представь, что нормальный текстовый редактор никто не написал и правь свои конфиги через ed или cat+grep+awk+sed.

Его написали. Он уже есть. Я прямо в нем сейчас письмо пишу. А твоего мегаредактора со схемой пока ещё нет. И попытки революций «сперва формат, потом тулза» чаще всего ведут к ещё одному формату без тулзы. Так что сперва пруфы, потом разговоры о переходе.

Я говорю про Unixway. Вещи должны быть как можно более простыми. Иначе архитектурно всё усложняется (при этом людям становится сложнее управлять происходящими процессами) и начинает тормозить.

Будет о чем говорить, когда ты напишешь PoC такого редактора.

Да, но согласись, что такие сложные вещи должны начинаться с теоретического обсуждения. И согласись, положа руку на сердце, что по моему описанию работа с конфигурацией logrotate выходит проще и быстрее.

Да, но согласись, что такие сложные вещи должны начинаться с теоретического обсуждения. И согласись, положа руку на сердце, что по моему описанию работа с конфигурацией logrotate выходит проще и быстрее.

Пока что нет. Более того: как мне оставить комментарий к блоку правил?

Вещи должны быть как можно более простыми.

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

и начинает тормозить.

Вот тут совсем не согласен. Если у нас реестр будет хранить бинарные данные, то работа с ними будет однозначно быстрее.

Для таких случаев полезно иметь конвертор, который не просто конвертировал бы текст из UTF-8 в KOI8-R, но и дампил бы в него символы сверх KOI8-R их названиями. Например, «alpha», «niti», «shao», «каф», «цади»,... и т.д. К сожалению, я пока ещё такое не организовал.

Более того: как мне оставить комментарий к блоку правил?

comment:str = «Всякая фигня»

Пока что нет.

Хочешь сказать, что тот самый конфиг для logrotate ты текстом напишешь быстрее? А как ты проверишь на ошибки? Прочитаешь ещё раз и запустишь logrotate?

Вот и надо начинать с теоретического обсуждения, чтобы все вопросы были решены ДО написания редатора, а не чтобы его переделывать потом 200 раз.

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

Кстати о птичках. Нафига тебе унификация значений? Какие такие парсеры тебе необходимо пейсать?

Возникнет гонка обращений к реестру и начнутся тормоза. В винде так и происходит.

Хочешь сказать, что тот самый конфиг для logrotate ты текстом напишешь быстрее?

Ага.

А как ты проверишь на ошибки? Прочитаешь ещё раз и запустишь logrotate?

Ага. Я это в любом случае сделаю, чтобы проверить, что я не проебался в логике.

о и дампил бы в него символы сверх KOI8-R их названиями

Круто! И как отличать просто текст «alpha» от символа «alpha»? Надо будет вводить какой-то префикс-модификатор. И тогда время работы функций работы с текстом будет больше, чем при нормальном юникоде. Смысл?

comment:str = «Всякая фигня»

Вот прям в произвольном месте?

Вот и надо начинать с теоретического обсуждения, чтобы все вопросы были решены ДО написания редатора, а не чтобы его переделывать потом 200 раз.

Теоретическое обсуждение это «эй парни, я вот считаю что моя хреновина (вот пруф) поможет сделать вашу жизнь лучше вот здесь и здесь (конкретные примеры, а не абстрактные парсеры); что вы об этом думаете?». Ну то есть ты как автор идеи должен знать, где конкретно она сделает чью-то жизнь лучше.