История изменений

Если ты вывод одной программы перенаправишь на ввод другой, то, да, ты получишь pipe. Но ты забываешь, что поток можно перенаправить и в файл, и в сокет. Прочитай внимательно вот это: http://xmodulo.com/tcp-udp-socket-bash-shell.html - тут ничего не говорится про пайпы, только лишь про сеть, но идет работа с stdin и stdout. Так что filter работает далеко не только с пайпами.

Хватит шланговать. Началось обсуждение пайпов здесь, и именно с твоей подачи:

Похоже ты под «текстовыми потоками» понимаешь сугубо пайпы. А имеется ввиду хранение и обмен информации в текстовом виде. Так что REST + JSON - хороший пример реализации этого принципа.

В чем отличие OpenRC от Systemd? (комментарий)

Так вот, я под текстовыми потоками понимаю именно stdin и stdout, а под текстовыми фильтрами — программы, которые принимают текст на stdin и возвращают текст на stdout. А что к ним подключено, пайпы там, или файлы, или именованные сокеты — уже третий вопрос.

А вот ты натягиваешь сову на глобус, пытаясь мне доказать, что «имеется ввиду <…> обмен информации в текстовом виде» и на основании этого пытаешься приплести сюда REST и вебню. Ты правда не замечаешь, как сам себе противоречишь уже битый час?

Открой исходник WEB страницы, на которую смотришь - текст; почему не какой-то скомпиленный бинарь аля Java bytecode, ведь браузеру было бы так проще?

Потому что так сложилось исторически. Если ты не в курсе, в своё время «скомпиленные бинари» в лице ActiveX и Flash были очень популярны, гораздо популярнее сложной логики на жабаскрипте, а сейчас обороты набирает WebAssembly.

почти все конфиги хранятся в тексте

«А ты на основании исключений правила не строй. Понятно, что там, где нужно постоянное вмешательство человека, никто в бинарном формате данные хранить или передавать не будет.»

Неужели даже и тени сомнения не проскакивает, что есть разные use case’ы, и не существует одного решения которое удовлетворило бы всех?

Неужели даже и тени сомнения не проскакивает, что ты порешь какую-то бессвязную чушь?

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

Я вот хочу поговорить про десктопы, и мне интересно зачем на десктопе бинарный лог. Зачем в десктопные дистры тянуть эту ерунду по дефолту?

В последний раз тебе повторяю: спроси у тех, кто «тянет эту ерунду по дефолту». Ответ будет очень прост: потому что ничего лучше ещё не придумали.

А такое твое отношение показывает, что ты даже и не пытаешь думать, а просто идешь на поводу у других.

Спасибо, я как-нибудь сам разберусь, думаю я или иду на поводу у кого-то.

Если ты вывод одной программы перенаправишь на ввод другой, то, да, ты получишь pipe. Но ты забываешь, что поток можно перенаправить и в файл, и в сокет. Прочитай внимательно вот это: http://xmodulo.com/tcp-udp-socket-bash-shell.html - тут ничего не говорится про пайпы, только лишь про сеть, но идет работа с stdin и stdout. Так что filter работает далеко не только с пайпами.

Хватит шланговать. Началось обсуждение пайпов здесь, и именно с твоей подачи:

Похоже ты под «текстовыми потоками» понимаешь сугубо пайпы. А имеется ввиду хранение и обмен информации в текстовом виде. Так что REST + JSON - хороший пример реализации этого принципа.

В чем отличие OpenRC от Systemd? (комментарий)

Так вот, я под текстовыми потоками понимаю именно stdin и stdout, а под текстовыми фильтрами — программы, которые принимают текст на stdin и возвращают текст на stdout. А что к ним подключено, пайпы там, или файлы, или именованные сокеты — уже третий вопрос.

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

Открой исходник WEB страницы, на которую смотришь - текст; почему не какой-то скомпиленный бинарь аля Java bytecode, ведь браузеру было бы так проще?

Потому что так сложилось исторически. Если ты не в курсе, в своё время «скомпиленные бинари» в лице ActiveX и Flash были очень популярны, гораздо популярнее сложной логики на жабаскрипте, а сейчас обороты набирает WebAssembly.

почти все конфиги хранятся в тексте

«А ты на основании исключений правила не строй. Понятно, что там, где нужно постоянное вмешательство человека, никто в бинарном формате данные хранить или передавать не будет.»

Неужели даже и тени сомнения не проскакивает, что есть разные use case’ы, и не существует одного решения которое удовлетворило бы всех?

Неужели даже и тени сомнения не проскакивает, что ты порешь какую-то бессвязную чушь?

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

Я вот хочу поговорить про десктопы, и мне интересно зачем на десктопе бинарный лог. Зачем в десктопные дистры тянуть эту ерунду по дефолту?

В последний раз тебе повторяю: спроси у тех, кто «тянет эту ерунду по дефолту». Ответ будет очень прост: потому что ничего лучше ещё не придумали.

А такое твое отношение показывает, что ты даже и не пытаешь думать, а просто идешь на поводу у других.

Спасибо, я как-нибудь сам разберусь, думаю я или иду на поводу у кого-то.