Раздумывая над способами модернизации командной строки UNIX, Александр Ларсон (Alexander Larsson), активный разработчик GNOME и мантейнер таких проектов, как Nautilus, Gnome-vfs и Dia, предложил (http://blogs.gnome.org/alexl/2012/08/10/rethinking-the-shell.../) в своем блоге новый способ объединения команд с помощью пайпов, основная идея которого заключается передаче через канал не простых потоков неструктурированных данных, а объектов, представленных в бинарной форме. По словам Александра, его идея может сделать командный интерфейс более гибким, но не таким переусложненным как Microsoft PowerShell.
В качестве основы для представления объектов Александр предложил использовать тип данных GVariants (http://developer.gnome.org/glib/stable/glib-GVariant.html) из библиотеки Glibc, используемой также в GTK+ и GNOME. Он реализовал несколько утилит, повторяющих функциональность стандартных UNIX-команд ps, sort, head и других, которые принимают на вход и выдают на выходе объекты типа GVariants, причем в случае, если вывод осуществляется в терминал или принимающая команда не поддерживает на входе объекты, данные будут переданы в текстовой форме. Например, вывод его версии ps в терминал будет выглядеть так:
<font color="#461b7e">$ dps
<{'pid': <uint32 1>, 'ppid': <uint32 0>, 'euid': <uint32 0>, 'user': <'root'>,...
<{'pid': <uint32 2>, 'ppid': <uint32 0>, 'euid': <uint32 0>, 'user': <'root'>,...
...
</font>Применив к этому выводу другие утилиты можно легко отсортировать объекты по необходимым полям и выполнить их фильтрацию на основе тех или иных полей:
<font color="#461b7e">
$ dps | dfilter euid \< 1000 | dsort rss
<{'pid': <uint32 1>, 'ppid': <uint32 0>, 'euid': <uint32 0>, 'user': <'root'>,
<{'pid': <uint32 769>, 'ppid': <uint32 745>, 'euid': <uint32 0>, 'user': <'root'>,
...
</font>
В конце-концов можно использовать специальные утилиты для вывода данных удобочитаемом виде:
<font color="#461b7e">
dps | dfilter euid \< 1000 | dsort rss | dhead 4 | dtable pid user rss vsize cmdline
pid user rss vsize cmdline
1 'root' 24408 61488 '/usr/lib/systemd/systemd'
769 'root' 16028 108000 '/usr/bin/Xorg :0 -background none -logverbose 7 -seat seat0 -nolisten tcp vt1'
608 'root' 15076 255312 '/usr/bin/python /usr/sbin/firewalld --nofork'
747 'root' 8276 452604 '/usr/sbin/libvirtd'</font>
Как говорит Александр, такой подход существенно расширяет возможности обработки данных, позволяя, например, применять к выводу типо-зависимые операции (сравнение euid с числом), выполнять правильное обрезание списка (без учета заголовка), работать одновременно со всеми полями объекта даже в том случае, если они не будут выведены на экран. Кроме того, все данные между командами передаются в бинарной форме, благодаря чему их обработка существенно упрощается.
URL: http://blogs.gnome.org/alexl/2012/08/10/rethinking-the-shell.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=34591
Идея может и стоящая, только на счет бинарной формы сомневаюсь - это ж сколько эксплойтов можно будет повытягивать из похабно написанных "парсеров" бинарных входных данных.
Подобные изменения для пользователя вообще не важны. Разве что обновится Coreutils. Новые возможности откроются для программистов.
наоборот. Программист в крайнем случае своим скриптом вывод распарсит, если лень с awk, grep и подобными возиться. А вот пользователю на основе такой штуки можно сделать gui.
> это ж сколько эксплойтов можно будет повытягивать из похабно написанных "парсеров" бинарных входных данных.Вы так говорите, как будто текстовые данные парсить безопаснее.
В libxml дыры находят гораздо чаще, чем в libpng, libjpeg и libtiff вместе взятых.
>> это ж сколько эксплойтов можно будет повытягивать из похабно написанных "парсеров" бинарных входных данных.
> В libxml дыры находят гораздо чаще, чем в libpng, libjpeg и libtiff
> вместе взятых.Я думаю, деление тут по сложный формат -- не сложный.
И сравнивать надо(*) libxml *и* lib{png,jpeg,tiff} против grep, awk, sed, sort, ...Все сравнили? Теперь дружно аплодируем брату Леонида из новости выше.
(*)Нет, я не настаиваю.
С технической точки зрения парсить TLV-подобный формат не сложнее чем произвольный текст, и посадить там багов еще суметь надо. Но проблема не в том. Проблема в том что то что валят на экран эти утили - нечитабельно для человеков. А сисадминские утили - они не столько для машины, сколько для человека.
> Проблема в том что то что валят на экран эти утили - нечитабельно для человеков.И вы тоже новость не читали?
> И сравнивать надо(*) libxml *и* lib{png,jpeg,tiff} против grep, awk, sed, sort, ...Хорошо. Заменим libxml на libpcre. Стало лучше?
>> это ж сколько эксплойтов можно будет повытягивать из похабно написанных "парсеров" бинарных входных данных.
> Вы так говорите, как будто текстовые данные парсить безопаснее.Да.
Если это не xml ;)P.S.
> В libxml дыры находят гораздо чащеПолностью согласен)
> Да.
> Если это не xml ;)Без разницы. XML - это текст.
> Да.
> Если это не xml ;)И не plain text, который нужно парсить регулярными выражениями. Потому что мало-мальски фичастые реализации regexp по дырам даже превосходят libxml.
> Полностью согласен)
Насчет libpcre, несомненно, тоже согласитесь.
> Идея может и стоящая, только на счет бинарной формы сомневаюсь - это
> ж сколько эксплойтов можно будет повытягивать из похабно написанных "парсеров" бинарных
> входных данных.Не больше, чем из нынешних текстовых парсеров.
Не самая идиотская идея для гномера. Если ещё сделать конвертер текста в этот его бинарный формат, такие тулзы точно будут полезны. Однако, причём тут "новая реализация неименованых каналов", если просто предлагается некий формат передаваемых данных?
> Не самая идиотская идея для гномера. Если ещё сделать конвертер текста в
> этот его бинарный формат, такие тулзы точно будут полезны. Однако, причём
> тут "новая реализация неименованых каналов", если просто предлагается некий формат передаваемых
> данных?Торвальдс же _сделал_ новый printk (я знаю, что не он лично). И **почти** пропустил переделку из строчно-ориентированного вывода в ориентированный на записи.
Теперь все хотят!! Это *Н*ужно!
+++А вот ещё пользовательские пайпы гонять ч-з udev... Инновационно! Автогеном!1
А при том, что новость написана так, что даже исправлять ее бесполезно.
Речь о расширении функционала.
I created a format negotiation system for pipes such that for “normal” pipes or other types of output we output textual data, one variant per line. But, if the destination process specifies that it supports it we pass the data in raw binary form.
> Речь о расширении функционала.http://ru.wikipedia.org/wiki/Функционал
не нашёл там ничего про это.
http://ru.wikipedia.org/wiki/Теорема_Хана_—_Банаха
Давно пора.
Спасибо нет. Давно пора чтобы такие вот леннарты и александры свалили венду улучшать.
> Спасибо нет. Давно пора чтобы такие вот леннарты и александры свалили венду улучшать.Спасибо за то, что высказали ваше бесполезное и неконструктивное мнение. Сообщите нам свой адрес и передвижной биореактор прибудет к вашему дому в течение трёх дней в удобное вам время. Услуга бесплатна, достаточно лишь сообщить оператору своё имя (чтобы свериться со списком).
Голос из биореактора - изыди
> Давно пора.
> Спасибо за то, что высказали ваше бесполезное и неконструктивное мнение./0
> Спасибо нет. Давно пора чтобы такие вот леннарты и александры свалили венду улучшать.Не дождетесь на своей винде. Так и будете сидеть с технологиями прошлого века за красивыми картинками.
> Не дождетесь на своей винде.Вы все просто не видели же поверсхела! Там же уже же всё это есть, а эти ваши гномы - позапрошлый век!! </яслыхала></summoning Ваня>
> Спасибо нет. Давно пора чтобы такие вот леннарты и александры свалили венду
> улучшать.+1 Пока эти товарищи не опустили юниксы до уровня винды.
> +1 Пока эти товарищи не опустили юниксы до уровня винды.Таким специалистам по виндам, как вы, не стоит рассуждать о перспективах развития unix.
> Таким специалистам по виндам, как вы, не стоит рассуждать о перспективах развития
> unix.Не вы ли тот аноним, кто где-то здесь ранее рассуждал на тему, чтО безопасникам следует вбивать себе в голову киянкой? Очень уж стелите похоже, юноша.
На ровном месте плодить бинарный мусор?
> На ровном месте плодить бинарный мусор?20 лет на ровном месте плодили текстовый мусор, и ничего.
>> На ровном месте плодить бинарный мусор?
> 20 лет на ровном месте плодили текстовый мусор, и ничего.И ничего плохого не было. "Мусор" этот было просто обрабатывать - от кучи стандартных утилит, до глазок оператора, смотрящих на вывод программы в пейджере.
Зато теперь, забыл надеть на stdout "презерватив" - терминал нечитаем. Это, конечно, "цветочки".
> Давно пора.Не, спасибо. Что-то не хочется видеть ps в виде как этот красавец предложил, так что надо трехэтажным матом^W фильтром крыть чтобы оно читаемым стало. Вводить вместо 2 букв три этажа фильтров лично мне дико влом.
> Не, спасибо. Что-то не хочется видеть ps в виде как этот красавец
> предложил, так что надо трехэтажным матом^W фильтром крыть чтобы оно читаемым
> стало.Очевидно, новость вы не читали. Но осуждаете.
>> Не, спасибо. Что-то не хочется видеть ps в виде как этот красавец
>> предложил, так что надо трехэтажным матом^W фильтром крыть чтобы оно читаемым
>> стало.
> Очевидно, новость вы не читали. Но осуждаете.Не понимаю, зачем таким деятелям вообще читабельный вывод, если они все равно читать его не будут, а сразу бросятся писать гневные комментарии?
Ну х*й знает. Что будет если сделать dps в файл и прочитать на другой архитектуре или отрпавить через ssh на другую архитектуру? Какие будут накладные расходы на сериализацию/десериализацию этих данных? Что делать если мне таки нужен вменяемый текстовый вывод, постоянно pipeline клепать? Насколько эти pipeline будут менее эффективны обычного текстового вывода? Тем более если речь идёт о "работать одновременно со всеми полями объекта даже в том случае, если они не будут выведены на экран" - а нахрена мне с ними работать, если они не будут выведены?И не glibc а glib. И да - нет, не слышал. Что у меня, без их костыльной библиотеки, пайпы работать не будут?
> Ну х*й знает.Поддерживаю.
> Что будет если сделать dps в файл и прочитать на другой архитектуре или отрпавить через ssh на другую архитектуру?Все числа в network byte order, так что все нормально прочитается.
> Какие будут накладные расходы на сериализацию/десериализацию этих данных?<= чем на сериализацию в поток текста.
> Что делать если мне таки нужен вменяемый текстовый вывод, постоянно pipeline клепать?Ну может додумаются до дефолтного представления в виде таблицы, вместо закорючек из повершелла.
> Насколько эти pipeline будут менее эффективны обычного текстового вывода?Нинасколько.
> а нахрена мне с ними работать, если они не будут выведены?dcat orders.csv | dfilter date='17 Aug 2012' | dtable name price 'все заказы за сегодня' #псевдокод
> Что у меня, без их костыльной библиотеки, пайпы работать не будут?Вот привязка к гному это да, самое обескураживающее в этой затее.
>Вот привязка к гному это да, самое обескураживающее в этой затее.
>Package: libglib2.0-0
>Source: glib2.0
>Depends: libc6 (>= 2.9), libpcre3 (>= 7.7), libselinux1 (>= 1.32), zlib1g (>= 1:1.1.4)А где гном?
>>Package: libglib2.0-0
> А где гном?glib - исконно гномерская либа. Слона то я и не приметил? :)
>glib - исконно гномерская либа. Слона то я и не приметил? :)Так GNOME зависит от GLib, а не наоборот! И в чем привязка к гному?
В этой либе. В привязке к технологиям на которых построен гном.
> В этой либе. В привязке к технологиям на которых построен гном.NIH такой NIH.
> NIH такой NIH.Что-них? Сейчас то все и без гномолибы работает.
> <= чем на сериализацию в поток текстаНеправда. Сериализация/десериализация каждого поля будет в каждом пайпе. При том что предполагается что полей больше, чем нужно в итоговом выводе.
>> Насколько эти pipeline будут менее эффективны обычного текстового вывода?
> Нинасколько.Т.е. ps, который сразу форматирует как надо, будет небыстрее пайплайна из 5 утилит, с 4 каналами с сериализациями/десериализациями? Ну-ну.
>> а нахрена мне с ними работать, если они не будут выведены?
> dcat orders.csv | dfilter date='17 Aug 2012' | dtable name price 'все заказы за сегодня' #псевдокодИмелось в виду то, что если ps будет выдавать все поля, будет оверхед по обработке ненужных мне.
> Неправда. Сериализация/десериализация каждого поля будет в каждом пайпе. При том что предполагается что полей больше, чем нужно в итоговом выводе.Как и при работе с текстовыми данными, только оверхед меньше.
> Т.е. ps, который сразу форматирует как надо, будет небыстрее пайплайна из 5
> утилит, с 4 каналами с сериализациями/десериализациями? Ну-ну.Да.
> Имелось в виду то, что если ps будет выдавать все поля, будет оверхед по обработке ненужных мне.
А в текстовом формате его типа нет?
>> Т.е. ps, который сразу форматирует как надо, будет небыстрее пайплайна из 5
>> утилит, с 4 каналами с сериализациями/десериализациями? Ну-ну.
> Да.Ну на этом можно и закончить.
> Какие будут накладные расходы на сериализацию/десериализацию этих данных?Всяко меньше чем при конвертировании в текст/из текста.
> Что делать если мне таки нужен вменяемый текстовый вывод, постоянно pipeline клепать? Насколько эти pipeline будут менее эффективны обычного текстового вывода? Тем более если речь идёт о "работать одновременно со всеми полями объекта даже в том случае, если они не будут выведены на экран" - а нахрена мне с ними работать, если они не будут выведены?
Вы новость читали?
> если вывод осуществляется в терминал или принимающая команда не поддерживает на входе объекты, данные будут переданы в текстовой форме
> принимающая команда не поддерживает на входе объектыА как об этом будет оповещаться передающая сторона?
Мне очень понравилась идея объектной консоли, как PowerShell.
Правда реализацию в MS как всегда подкачала и получилось из PowerShell УГ.С объектами на много наглядней работать, с автокомплитом из коробки правильным пространством имен со схожими параметрами... В общем тут нужно сначала такую консоль спроектировать тщательно, а не как вышеупомянутые ребята.
> Правда реализацию в MS как всегда подкачала и получилось из PowerShell УГ.А я-то ждал Ваню...
> С объектами на много наглядней работать,
smalltalk, lisp, fotrh??
> с автокомплитом из коробки правильным пространством
>В общем тут нужно сначала такую консоль спроектировать тщательно, а не как вышеупомянутые ребята.Да. Именно! Предлагаю подождать, когда Граждане Учёные сделают тнам хорошоу. +++А то развеои тут.
У MS так сплошь и рядом - хорошая идея (иногда - ворованная), но реализация - повеситься можно. Особенно эпично это было с COM - красивейшая идея (если кто не знает - любой кусок Офиса как минимум раньше был COM-объектом и внешним клиентам программно было доступно всё, что мог пользователь) - но немыслимо тяжелая и неудобная реализация. PowerShell явно из этой же области.
> PowerShell явно из этой же области.Ну так реализуется индусскими ботами. Для галочки. Чтобы манагер в туман свалил. А у *никсоидов такое реализуется теми кто потом с этим еще и работать собирается. Ну а сам себе мало кто враг. А вот манагеру и каким-то сферическим кастомерам в вакууме - кто угодно с удовольствием отгрузит любой булшит.
И в чём проблема в реализации PowerShell? Особенно если смотреть 3 версию.
>новый способ объединения команд с помощью пайпов, основная идея которого заключается передаче через канал не простых потоков неструктурированных данных, а объектов, представленных в бинарной форме.Во первых - такая идея каждые 3 года взрывает интернеты :)
И чо - хоть где то прижилось? Видимо от большого удобства :)
Очередной гномовец снова изобрёл велосипед - ну и? Все и так знают что они там все шЫрки конченные, пусть в свою гомось всталяют - убер же будет вещь :)
Добрый день,поправьте, пожалуйста, текст новости, а именно этот фрагмент:
«...Александр предложил использовать тип данных GVariants из библиотеки Glibc, используемой также в GTK+ и GNOME.»здесь должно быть не «Glibc», а «glib».
Владимир, под текстом статьи есть кнопка — «Исправить»
> поправьте, пожалуйста, текст новости, а именно этот фрагмент:
> «…Александр предложил использовать тип данных GVariants из библиотеки Glibc, используемой
> также в GTK+ и GNOME.»…здесь должно быть «я джва года ждал такую реализацию!»
afair, о чём-то подобном ещё ...надцать лет назад флеймили в ru.linux
Хм, его текстовое представление - это ж JSON с заменой символов. Так JSON и использовали бы уже... Вообще - идея была бы неплоха, если б они:а) использовали что-то более-менее стандартное и эффективное для бинарного формата, а не своё загадочное чудо. MsgPack тот же или protobufs
б) использовали бы что-то стандартное для текстового представления - JSON скорее всего
в) показали интероперабельность этих штук между разными платформами - 32 vs 64 и little-endian vs big-endian
г) заложили в утилиты вывод в стандартном формате того, какие поля они отдают, какого типа и краткое описание каждого поля. Затрат на это надо мало, а получилась бы возможность сделать GUI-оболочку для использования пайпов далёким от программирования людом. Вот это было бы вполне себе киллер-фичей. Потому что power user и так махнет sed/awk/grep и получит то что надо.
Вообще, основная болезнь гномеров - это стремление всё сделать в своём мирке. Ну как он себе представляет, чтобы кто-то за пределами Gtk принял их GVariant?
Интересный ты такой. У нас pulseaudio и systemd приняли как ману небесную и journald не за горами, а ты про такие мелочи :)
Это две большие разницы. Если принять GVariant за основу, то все программы, использующие pipes будут тянуть glib. А оно мне надо в Qt?
так а qt все равно умер уже
> так а qt все равно умер ужеТолько в черепушках тулкитофобов. Вместе с мозгами
> так а qt все равно умер ужеМикрософтовские дроны мечатют. Вот только правда состоит в том что открытые проекты не мрут ровно до тех пор пока в них есть заинтересованные люди. Да, нет метода убить открытый проект по заказу пары особо жирных му...ков. Какая досада для Баллмера :)
Ой, да ладно. Вам что, восьмисот килобайт жалко? :D
Да.
Дело не в размере, дело в лишней зависимости.
> Ой, да ладно. Вам что, восьмисот килобайт жалко? :DДа, особенно в мелкой эмбеддовке.
Откуда в эмбеддовке неименованные каналы? Вы бы еще драйвер файловой системы в микроконтроллер запихнули.
> Вы бы еще драйвер файловой системы в микроконтроллер запихнули.ты, конечно, не поверишь, но…
хотя нафига там пайпы — я тоже не понимаю.
> Это две большие разницы. Если принять GVariant за основу, то все программы, использующие pipes будут тянуть glib. А оно мне надо в Qt?Впилить интерфейс пайпов в glibc, очевидно же.
Glib - просто набор абстракций для С. Тулкитофобия?
> Glib - просто набор абстракций для С. Тулкитофобия?Скорее непонимание нафиг чинить то что не сломано.
> Скорее непонимание нафиг чинить то что не сломано.Согласен. Зачем чинить старые ботинки, если можно просто выкинуть их и взять новые, удобные и качественные?
GVariant - в ядро! </trollmode>
BSON уже существует :)
Всё верно, только в качестве бинарного формата нынче следует брать не эти ad hoc хаки, а CBOR (RFC 7049).
В новости почему-то забыли упомянуть о том, что подобные объекты, благодаря Gvariants можно было бы пихать в dbus, позволяя тесно интегрировать dbus и shell.
Стоит также упомянуть, что такие изменения поломают совместимость с, например, BSD, но gnome уже давным-давно официально заявил, что на маргинальных системах он работать не будет. Только Linux.
Все правильно, пусть пилят. А эти ваши BSD нужны разве что на утюгах да кофеварках
> В новости почему-то забыли упомянуть о том, что подобные объекты, благодаря Gvariants можно было бы пихать в dbus, позволяя тесно интегрировать dbus и shell.Так dbus не сильнее нужен, чем это уродство.
Кому как. У меня, например, весь проект построен на dbus. А проект очень большой.
Ну, поздравляю. Скоро вы узнаете, что означает выражение "раб лампы".
Это скоро вот уже несколько лет никак не наступит. Впрочем если так рассуждать, то все мы рабы каких-то ламп. Вот у меня лампа очень даже комфортабельная.
> Ну, поздравляю. Скоро вы узнаете, что означает выражение "раб лампы".Быть рабом POSIX гораздо страшнее.
Погуглил, кстати, выражение "раб лампы", но так и не нашел четкой формулировки. Вероятно это что-то сугубо личное и простым смертным его не понять.
> Погуглил, кстати, выражение "раб лампы", но так и не нашел четкой формулировки.
> Вероятно это что-то сугубо личное и простым смертным его не понять.Великий Гугл заменил мозги и общее развитие? Это про Аладдина, утырок. :)
> Великий Гугл заменил мозги и общее развитие? Это про Аладдинащаз тебе скажут, что «мультики давно не смотрят».
> Кому как. У меня, например, весь проект построен на dbus. А проект
> очень большой.Соболезную.
Себе самому?
Нет. Тем кто использует Dbus.
Неаргументировано
> НеаргументированоУ противников dbus нет аргументов. Зачем? Ведь есть ненависть.
> У противников dbus нет аргументовтолько коряво написаный dbus. который, например, не так давно забыл убрать за собой сокет в /var/run/dbus, и после этого отказался работать. вообще. хотя в списке задач появлялся и никаких ошибок не выдавал. но соединиться с ним было нельзя. и вот этой — очень качественно и аккуратно написаной — программе даются рутовые привилегии.
вообще-то, такого прокола достаточно, чтобы не использовать dbus. это было бы простительно новорожденой софтине в статусе «альфа» или «пребета», но дбас-демону? его вообще никто не тестирует, похоже (ну, кроме несчастных юзеров, которым этот dbus впихнули).
и нет: я не собираюсь писать багрепорт. потому что не хочу, чтобы это дырявое гуано «развивалось».
если что, у меня коллекция тупняков дбаса была, когда по необходимости пришлось с ним работать. но лень архивы рыть. лично мне вышеописаного достаточно, чтобы сделать вывод о качестве программы.
Для начала, аргументы нужны за dbus. У меня вот висят в процессах какие-то dbus-launch и dbus-daemon, какого они жрут мои ресурсы? Я просто грохнул и процессы и бинарники, и что вы думаете? Ничего не изменилось. Итого, это ненужная сущность, которая жрёт память и диск, и быть её не должно. А если углубляться, оно обеспечивает взаимодействие процессов в обход стандартных средств безопасности как-то прав, за что надо расстреливать. Но главное то, что оно не нужно.
ну, на самом деле идея-то неплохая. реализация вот только как обычно…
Ну конечно. Если из консоли носа не высовывать. Тогда действительно непонятно, зачем он нужен. А уменя он применяется для общения между независимыми процессами, работающими в качестве сервисов.
> Кому как. У меня, например, весь проект построен на dbus.он публичный? если да — то скажи, пожалуйста, название. чтобы я случайно в него не вляпался.
> он публичный? если да — то скажи, пожалуйста, название. чтобы я случайно в него не вляпался.GNU/Linux.
>> он публичный? если да — то скажи, пожалуйста, название. чтобы я случайно в него не вляпался.
> GNU/Linux.проходи мимо, даунам не подаю.
Публичный. Но в зависимостях никогда ни у кого не будет. Это платежный терминал.
> Так dbus не сильнее нужен, чем это уродство.Вы путаете dbus с собой.
В DBus и так что угодно ткнуть не проблема - есть клиент командной строки, есть биндинги для кучи языков.
И вот об этой проблеме гномеров я и говорил - они не замечают, что некоторые вещи, если уж реализовывать,надо делать уровнем ниже чем DE и независимыми от него. Впрочем, если уж VFS для работы со всякими zip и ssh никто до сих пор корректно не сделал - что тут говорить...
> Впрочем, если уж VFS для работы со всякими zip и ssh никто до сих пор корректно не сделалваш вброс неясен,
> для работы со всякими zip... есть avfs( не путать с aufs)
> и ssh... ну тут sshfs-fuse
Glib давно никак не привязан ни к Gnome ни даже к GTK. В отличии от, KDE с монструозными kdelibs, gnome зиждается на Glib и libgee. Эти библиотеки не имеют ничего общего ни с GUI ни с Gnome в частности. Просто кроссплатформенные библиотеки с объектами для языка С.
Такие вбросы может делать кдеешник, не знающий сути вопроса.
какой такой Linux ? Только в GnomeOS
Gnome OS рекламное название проекта по приведению дурацкого внутреннего устройства GNOME к некоторому гетерогенному виду, формированию SDK и привлечению новых девелоперов. Canonical, например, создает новости о том как они _собираются_обсудить_что-то_сделать_ или меняют плеер. Gnome Foundation назвал проект так, чтобы троли разрекламировали его по интернету за них и бесплатно. Не ведитесь на провокации.
> Gnome OS рекламное название проекта по приведению дурацкого внутреннего устройства GNOME
> к некоторому гетерогенному виду,Гетерогенному? Г-но отсортируют и разложат по полочкам? :)
> Гетерогенному? Г-но отсортируют и разложат по полочкам? :)Берегись, тебя хотят отсортировать!
$ echo " PID TTY TIME CMD"; ps | awk '$1 < 10000 ;' | sort -k 4
PID TTY TIME CMD
8724 pts/4 00:00:00 awk
8723 pts/4 00:00:00 ps
8725 pts/4 00:00:00 sortЕсли вся польза от этих бинарных пайпов только в этом, то не нужно.
> Если вся польза от этих бинарных пайпов только в этом, то не нужно.Вся польза от быдлокодеров - только в костылях.
> Вся польза от быдлокодеров - только в костылях.А еще надо бы набыдлокодить скрипт, который парсит текст и автоматически форматирует ширину полей в заголовке. Вот это был бы костыль так костыль!
# echo -ne 'А еще надо бы \nнабыдлокодить скрипт, который парсит\n текст и автоматически форматирует\n ширину полей в заголовке.\n Вот это был бы\n костыль так костыль!' | column -tА еще надо бы
набыдлокодить скрипт, который парсит
текст и автоматически форматирует
ширину полей в заголовке.
Вот это был бы
костыль так костыль!
headshot!
И получаем костыль, привязанный к позиции параметров, а в более сложных случаях ещё и к локали. Нет уж, идея правильная - формат должен быть типизированным с метаинформацией, пока это возможно и не попросили обратного - но реализацию товарищ придумал безумную.
> формат должен быть типизированным с метаинформацией, пока это возможно и не попросили обратногоровно наоборот. opt-in.
С днем велосипедиста!
Нет уж, давайте XML.
> Нет уж, давайте XML.И аппаратный аксель парсинга XML от МежДелМаша, ога, ога. :D:D:D
Да, как раз сейчас нарыл одну интересную реализацию - xml-coreutils.
Удивлен, что это еще не вошло в репозитории, очень перспективное и интересное костыле.
> Нет уж, давайте XML.Еще лучше. Особенно читать его глазами в 1 строку. Ах, настоящие джедаи пишут свой реформатер xml? Факью, настоящие джедаи, пишущие реформатеры xml!
> Нет уж, давайте XML.согласен.
Нет уж давай те за стандарт примем передачу сериализованных объектов Java, а ваша поделка пусть соответствует им.
> Нет уж давай те за стандарт примем передачу сериализованных объектов Java, а
> ваша поделка пусть соответствует им.Если заменить java на javascript, то я согласен.
почему не питон/перл/пхп/эрланг/ННН?
давайте ещё кодировку юникод-32. Чтоб уж точно совместимо с литл-эндиан и биг-эндиан.
>почему не питон/перл/пхп/эрланг/ННН?Потому что слишком медленно.
Мнда... Разум всё воспалённее и воспалённее :(
ничего плохого нет если команда (пусть для примера та же ps) будет иметь ключик по которой она выдает не текст а объект с полями в каком то формате (JSON или бинарник это ещё вопрос о котором стоит порассуждать что удобнее дальше обрабатывать) т.к. в следующей команде всегда будет работать легче со _структурированными_ данными нежели с простым текстом, который может меняться от версии, ошибок...
> нежели с простым
> текстом, который может меняться от версии, ошибок...Такой страх как правило испытывают сугубо вантузятники впервые столкнувшиеся с пайпами в линуксе. Через пол-года это у них проходит. Бывают конечно совсем запущенные случаи, но они погды не делают.
>> нежели с простым
>> текстом, который может меняться от версии, ошибок...
> Такой страх как правило испытывают сугубо вантузятники впервые столкнувшиеся с пайпами
> в линуксе. Через пол-года это у них проходит. Бывают конечно совсем
> запущенные случаи, но они погды не делают.Такие вполне закономерные опасения испытывают все, кто работает с пайпами.
Такой страх испытывает каждый, у кого ломались скрипты при смене локали. А особенно сильный - те, кто выяснил, что вывод ls для произвольного каталога вообще нельзя распарсить гарантированно корректно.
> Такой страх испытывает каждый, у кого ломались скрипты при смене локали.LANG=C scriptname
в особо запущенных случаях - LANG=en_US.utf8 scriptname> А особенно сильный - те, кто выяснил, что вывод ls для произвольного каталога вообще нельзя распарсить гарантированно корректно.
man stat
man find
man xargs
вам в помощь, благо входят в coreutils, и даже в busybox есть из коробки
в зависимости от сложности задачи - может хватить и простого stat.
> Такой страх испытывает каждый, у кого ломались скрипты при смене локали.за 10 с чем-то лет ни разу не ломались. ЧЯДНТ? умею LANG=?
> А особенно сильный - те, кто выяснил, что вывод ls для произвольного
> каталога вообще нельзя распарсить гарантированно корректно.и тогда человек -- опа! включил мозг и начал думать: а может, этот самый ls -La вовсе и не то, что надо использовать?
> за 10 с чем-то лет ни разу не ломались. ЧЯДНТ? умею LANG=?Наверное, просто не пользуешься парсингом текста в скриптах.
> и тогда человек -- опа! включил мозг и начал думать: а может,
> этот самый ls -La вовсе и не то, что надо использовать?А использовать надо сабж.
Согласен по поводу ключика. Но необходимость бинарного вывода сомнительна, ибо гуру говорят, что http://www.faqs.org/docs/artu/ch05s01.html
Обратите внимание на первое предложение. Действительно, что мешает сейчас передавать бинарные данные через пайплайн? Вся новизна предложенного подхода в GVariants или я чего-то не понял?
Гуру это писали во времена адского зоопарка архитектур и меньшего запаса наработок. Сейчас проблема работы с бинарью давно решена. Другое дело, что надо брать нормальные стандартные обкатанные форматы - хоть protobufs тот же, которые вылизаны в том числе в плане интероперабельности.
> Гуру это писали во времена адского зоопарка архитектур и меньшего запаса наработок.
> Сейчас проблема работы с бинарью давно решена.А как же тогда: "Text streams are a valuable universal format because they're easy for _human beings_ to read, write, and edit without specialized tools."
Это тоже больше не актуально?
Слава Роботам, чо.
нет, не нужно ключиков, пускай это будет отдельный набор утилит, coreutils попрошу оставить как есть.
Это взрыв мозга!!! - капец какой будет: все gnu utils переписывать,
вообще то еще миллион скриптов у каждого имеется которые парсят текст,
пусть мсье еще бинарный реестр забахает вместо /etc - да на уровне ядра,
а то как-то неудобно с ним работать и пусть гламурнее гнома пилит, пока еще его в дистрибы
включают - непорядок. - Уже наболело, ведь же нормальный DE был, ну что за
атрофия фантазий, сколько можно и так народ разбегается
.... - разочарованный, пока еще пользователь гнома 2.32
> вообще то еще миллион скриптов у каждого имеется которые парсят текст,Если объекты на входе не поддерживаются - передается текст.
> пусть мсье еще бинарный реестр забахает вместо /etc - да на уровне ядра,
В арче пытались (rc.conf), но потом вернулись к традиционной юниксовой модели (разделение настроек по файлам).
> Если объекты на входе не поддерживаются - передается текст.из новости:
> <{'pid': <uint32 1>, 'ppid': <uint32 0>, 'euid': <uint32 0>, 'user': <'root'>,...Это и есть обещанный текст? Старым скриптам, конечно, "раз плюнуть" такое перемолоть!
> из новости:
>> <{'pid': <uint32 1>, 'ppid': <uint32 0>, 'euid': <uint32 0>, 'user': <'root'>,...
> Это и есть обещанный текст? Старым скриптам, конечно, "раз плюнуть" такое перемолоть!А прочитать новость целиком - слабо?
А вам слабо прочитать внимательно? См. насчет использования специальных утилит для вывода "по-старому" (напомню, речь шла про старые скрипты, где как-то не предполагалось использование этих ОТДЕЛЬНЫХ "специальных" утилит).
А почему не JSON в качестве данных? Думаю он бы лучше подошел
потому что json тоже надо парсить (дабы получить те же бинарные структуры данных), а это накладные расходы
> потому что json тоже надо парсить (дабы получить те же бинарные структуры
> данных), а это накладные расходыбинарные данные из пайпа тоже придётся парсить в бинарные данные в памяти.
а json наверное самый быстрый формат в плане парсинга.
И с готовой возможностью получать данные из большого количество языков, не привязываясь к GVariant
потому, что лучше yaml
Не нужно предлатать ничего:--output=text (default, plain text)
--output=json
--output=xml
или ps, ps_xml, ps_json
а там пусть выбирает кому что удобнее.
я бы ещё добавил и pdf, odf, docx/xlsx, dbf, jpg, png и "опубликовать в твиттере" (--output=twitter, специально для Д.А.Медведева)
> --output=text (default, plain text)
> --output=json
> --output=xmlПоттеринг так для логов сделал. Теперь его за это ненавидят.
Поттеринга ненавидят за то, что дефолт неправильный и за то что он это прибил гвоздями к systemd. Тем более, что его штука не делает ничего, что не мог бы делать текстовый формат + отдельный файл индекса (за исключением экономии места - но на это нынче точно плевать).
А также за то что отрастил systemd до мегабайта. Ничего себе сходил за хлебушком^W^W^W инит-переросток!
> А также за то что отрастил systemd до мегабайта. Ничего себе сходил
> за хлебушком^W^W^W инит-переросток!Ай-яй-яй, такой виндый специалисты по Unix, а про опции configure не в курсе.
> Поттеринга ненавидят за то, что дефолт неправильныйPlain text в стиле syslog - неправильный? Забавно. А что тогда правильно? XML, как в Lumberjack?
> Тем более, что его штука не делает ничего, что не мог бы делать текстовый формат + отдельный файл индекса (за исключением экономии места
А также скорости работы.
> - но на это нынче точно плевать).
Особенно смешно смотрится на фоне комментария ниже
> А также за то что отрастил systemd до мегабайта. Ничего себе сходил за хлебушком^W^W^W инит-переросток!
Следующим этапом будет включение библиотеки "полезных функций" gllib в состав glibc.
Потом выпиливание "устаревших" функций языка C (printf например, чтобы Hello world не так просто писать было) и чистка кода glibc с целью "увеличения быстродействия и уменьшения размеров библиотеки".
В общем Пацан к успеху идет семимильными шагами.
Минимальная базовая система будет тянуть glib?!
NO WAI
Речь даже не о добавлении кода glib в glibc, а о крайне опасной тенденции к изменению чего либо без веских на то оснований (кроме ЧСВ конечно).
Самое страшное то, что это пропихивается в качестве стандарта де-факто. Потом вырисовывается очередное чудо с ЧСВ повыше и процесс повторяется снова...
Пока Поттеринги и им подобные не поймут, что им никогда не стать Денисом Ричи, этот круг идиотизма не разорвется.
Поттеринг молодец. Без его pulseaudio я бы сейчас не использовал две звуковые карты одновременно. Помнится раньше можно было только с бубном, а сейчас просто переключаю и все.Одна встроенная - на ней микрофон, другая слотовая - на ней динамики. На EMU 0404 нет микрофона, но зато звук очень хороший. Полупрофессиональная. http://medias.audiofanzine.com/images/normal/e-mu-0404-36303...
А я вот без всякого пульса спокойно назначая альзовским программам нужное устройство (тоже де звуковых). Насколько я помню, альзовская либа даже из environment умеет эту настройку брать.
ппц, без его pulseaudio я прямо сейчас использую _одну "карту"_, как _три виртуальные_, разбив выходы для 7.1 на 3 отдельных stereo, причём один stereo-выход гонит в mono, предварительно собирая звук из двух каналов в один (потому что телек, на который он идёт, stereo не держит, а звуки из одного канала терять не хочется).
а ещё у меня тут есть BT-dongle и BT-гарнитура, на которую тоже можно отсюда гнать звук, одновременно спарив с ящиком и телефоном (http://www.mobile-review.com/accessories/review/sonyericsson...) -_-
всё на голой alsa. такая вот блаженная технологическая оргия, без грязных лисапедов.и когда я куплю себе http://www.ixbt.com/proaudio/esi-juli@.shtml, которую воткну рядышком, ничего, кроме alsa, мне всё равно не понадобится.
так что, засуньте-ка этот pulseaudio себе в tarball, и не выкладывайте его в эти наши интернеты, пожалуйста :/
>[оверквотинг удален]
> один (потому что телек, на который он идёт, stereo не держит,
> а звуки из одного канала терять не хочется).
> а ещё у меня тут есть BT-dongle и BT-гарнитура, на которую тоже
> можно отсюда гнать звук, одновременно спарив с ящиком и телефоном (http://www.mobile-review.com/accessories/review/sonyericsson...)
> -_-
> всё на голой alsa. такая вот блаженная технологическая оргия, без грязных лисапедов.
> и когда я куплю себе http://www.ixbt.com/proaudio/esi-juli@.shtml, которую воткну рядышком,
> ничего, кроме alsa, мне всё равно не понадобится.
> так что, засуньте-ка этот pulseaudio себе в tarball, и не выкладывайте его
> в эти наши интернеты, пожалуйста :/Честно, не знаю как сейчас и что у меня там со звуком работает.. Не сочтите за неуважение, для всего этого alsa требовала детальной настройки и понимания или все автоматически подхватывается?
ну откуда alsa или чему-то ещё знать, что я хочу вместо quadro, например, отдельные смешанный mono и stereo ?)
с какого чёрта вообще технике "автоматически" делать то, чего её хозяин не может понять и даже полноценно представить, как это должно выглядеть ?но вот из-за радости балбесов, которые не могут (а точнее - _не хотят_) найти менюшку для выбора подходящего звуковывода, теперь всем нам жевать через ненужную гламурную прослойку, рассчитанную на кастрированные чипы HDA (чего Леннартчик не скрывает и гордится) с исключительно программной обработкой и лишней буферизацией.
а ещё, это же так здорово, когда включаете вы музычку на портативке ("телефоне"), а у вас pulse жрёт процессорного времени столько же или даже больше чем звукоигрун ! батарейка просто в восторге :/
но там, похоже, уже выхода нет, ибо клепатели мобильных ОСей - не большие любители красивых технологических решений нынче, и другой способ динамически смешивать и гонять каналы искать они вряд ли будут. при том, что плевал Большой П на их нужды и любые аппаратные возможности, ведь "будущее за универсальными решениями - жирными CPU", а стало быть - и за ленивыми кодошлёпами и невежественными потребителями (нет, не просто "владельцами", потому что именно "потребитель" рано или поздно либо сам сломает, не расчитав, либо присосётся к изначально дефективному говну, неизбежно перепокупая его снова и снова).вообще, если речь о чем-то кроме встроеной звуковушки, то тут сам Патрик приказал зарубить pulseaudio, и удостоверится, что железка отрабатывает на максимуме своих способностей. потому что Большой П и его творения следить за этим отказываются, насколько я знаю.
но может быть более знающие люди расскажут нам о продвижениях PA в областях, кроме программного смешивания каналов ? а то ему уже хз сколько отроду, а я до сих пор не могу полностью понять, что конкретно оно якобы делает и для чего.
без пульс аудио я мог нормально пользоваться звуковухой на ноуте, а вот с ним постоянные косяки в разных приложениях, которые не имеют native поддержки pulse.
> Пока Поттеринги и им подобные не поймут, что им никогда не стать
> Денисом Ричи, этот круг идиотизма не разорвется.Дениса Ричи подобные вам люди в свое время ненавидели не меньше, чем сейчас они ненавидят Поттера.
>> Пока Поттеринги и им подобные не поймут, что им никогда не стать
>> Денисом Ричи, этот круг идиотизма не разорвется.
> Дениса Ричи подобные вам люди в свое время ненавидели не меньше, чем
> сейчас они ненавидят Поттера.Раньше чтоб сказать "Я могу сделать это лучше", и тебя хотя бы послушали,
нужно было иметь минимум кандидатскую или докторскую.
А теперь, каждое говно, которое может говорить - уникум.Есть амерекосский закон продажы товара - Чтоб продать товар, нужно создать
в нём потребность. То есть проблему, которую ваш товар решит!Иобанпидор Поттеринг из жопы высосал проблему с логами, с /dev/eth0, systemd,...
и впарил лохам свои решения, а фидорасы и сочувствующие рапиарили это до ноу-хау.Вы бля, как дети малые, - вас в мозг ебуут, а вы крепчаете!
> Речь даже не о добавлении кода glib в glibc, а о крайне
> опасной тенденции к изменению чего либо без веских на то оснований
> (кроме ЧСВ конечно).Если вы ничего, кроме ЧСВ, не понимаете - это ваши личные проблемы.
> NO WAIСогласен. А вот инглиш неплохо бы подучить. А то если вы даже протест не можете выразить - выглядит смешно :)
особенно смешно выглядят высоколобые комментаторы, не улавливающие шуток и занудно поясняющие, что «так не бывает». NO WAI!
И в чём шутка? Где именно надо смеяться?NO ПУТИ(н)?
да нигде не надо, расслабься.
т.е. юмор малограмотных линуксойдов. Лопата.
Мне одному кажется, что в преддверии GnomeOS будет всё больше "улучшений", направленных на герметизацию окружения Gnome, в том числе - системных?
>>dps | dfilter euid \< 1000 | dsort rss | dhead 4 | dtable pid user rss vsize cmdlineps aux | awk '$6>0 {print $2"\t"$1"\t"$6"\t"$5"\t"$11}' | sort -k3n |head -n5
После выхода MS PowerShell идея просится в unix, т.к. текст хорош для обработки человеком, а между программами удобней что-то более объектное. Ждем адекватную реализацию не привязанную к Gnome и Glib.
http://tinyurl.com/dxbxs6f
> После выхода MS PowerShell идея просится в unix, т.к. текст хорош для
> обработки человеком, а между программами удобней что-то более объектное.Вот только простите, но ps - он для человеков наполовину. А в powershell пи...ц какой-то понаворотили. С километровыми командами, задроченными абстракциями, тормозным дотнетом в комплекте и прочая. По поводу чего оно тормозит, взрывает мозг и просто вымораживает, особенно с учетом никаковски работающего автокомплита. Вы конечно извините, но *nix-овые шеллы не в пример юзабельнее. И не надо чинить то что не сломано. MS вон "починил". Такой crapwreck получился что *nix-овым шеллам и не снилось.
> Вот только простите, но ps - он для человеков наполовину. А в powershell пи...ц какой-то понаворотили. С километровыми командами, задроченными абстракциями, тормозным дотнетом в комплекте и прочая. По поводу чего оно тормозит, взрывает мозг и просто вымораживает, особенно с учетом никаковски работающего автокомплита. Вы конечно извините, но *nix-овые шеллы не в пример юзабельнее. И не надо чинить то что не сломано. MS вон "починил". Такой crapwreck получился что *nix-овым шеллам и не снилось.Ни в коей мере не защищаю MS, но идеи у них бывают очень здравые, пусть и с дурными реализациями. Я к powershell отнесся сперва с большой иронией - мол таки бэкпортировали шелл из юникса через дцать лет, пока не узнал подробности реализации. То что утилиты оперируют объектами предоставляя друг другу внятный API, по-моему очень логично и перспективно для скриптования. То что в юниксе в конфигах и при обработке разной системной инфы принято оперировать текстами - историческое наследие и давно уже не повод для гордости.
очень перспективно, очень. шаг влево-вправо беги дотнет изучать. километровые портянки для того что в юнихах делается в несколько букв. а с микрожеланием выпилить всё по максимуму и юзать этот пауршелл настают совсем счастливые времена. можно поискать как там из ексченджа что-нить вытянуть - раньше было на раз два в гуях, сейчас только хардкор скрипты. или вон для ихнего линксервера чтобы порты используемые поменять - это шедевр настроек.
если всё это скриптами пауршеловскими обмазать то это будет очень перспективно
Человеку - текст/GUI, а для программ - библиотека + скриптовый движок. Зачем еще одна сущность? Просто кому-то лень делать нормальную библиотеку. Посмотрите, например, на curl. Все, что можно делать из командной строки, можно делать через библиотеку (точнее наоборот).
Только бинарная сериализации в соответствии с принятыми международными стандартами ECMA-335 и ISO/IEC 23271 может стать той "серебрянной пулей" которая позволит решить все проблемы связанные с передачей объектов между процессами как локально так и удалённо.
Кстати в .Net сериализация реализована на SOAP. В GVariant что-то наподобие кодирования SSL сертификата. тип, [длина,] байт[, байт]
>может стать той "серебрянной пулей"...Это по Фрейду? :)
Пуля имеет только одно предназначение - убивать :(
Убить все проблемы - разве это плохо?
> Убить все проблемы - разве это плохо?Так это ж как гидра: одну бошку срубил, две выросло. Так, навскидку:
1) Читабельность вывода убита. TLV - отличные структуры. Кроме случая когда придется их декодировать глазами в стандартном выволе утилей или писать трехэтажные маты^W фильтры для окультуривания этого пи...ца.
2) Парсинг формата усложнится.
3) Предлагается всем всучивать гномовскую либу. Нормально, блин: "hello world: 17 errors, 34 warnings".
> 1) Читабельность вывода убита. TLV - отличные структуры. Кроме случая когда придется
> их декодировать глазами в стандартном выволе утилей или писать трехэтажные маты^W
> фильтры для окультуривания этого пи...ца.Еще один, не читавший новости.
>>может стать той "серебрянной пулей"...
> Это по Фрейду? :)Это очевидно по Бруксу :)
>>>может стать той "серебрянной пулей"...
>> Это по Фрейду? :)
> Это очевидно по Бруксу :)...по ван Хельсингу, чего там!=) //оговорки,да
что за бред?
> все проблемы связанные с передачей объектов между процессами как локально так и удалённо....и породить 100500 новых проблем...
>Убить все проблемы - разве это плохо?Убить все проблемы можно только ликвидировав их источник, точно так же как лучшее лекарство от всех болезней - топор :(
> Убить все проблемы можно только ликвидировав их источник...Источник всех проблем консервативные взгляды старой школы unix-way.
Новое молодое поколение не хочет мирится далее с отсутствием прогресса в вопросе стандартиризации обмена бинарными объектами между локальными и удаленными процессами.
Только ликвидировав старую школу и приняв в качестве стандарта общепринятый международный стандарт ECMA-335 мы сможем достичь новых высот.
Использование стандартов продвигаемые передовой командой разработчиков, позволит расширить границы для входа на новую ступень эволюции и начать процесс проникновения в альтернативные области на новом не доступном до сего момента уровне.
десктопы.
не, можете минусовать.
можете объяснять причины.
можете строить прогнозы.
я всё это знаю, но пока линукс на десктопах - всё же экзотика.
Мне в последнее время кажется, что источник проблем - это толпы "студентов", не знающих чем себя занять, и норовящих залезть своими шаловливыми ручками в код который писался и отлаживался годами, а то и десятилетиями, и наворотить там делов.
> Источник всех проблем консервативные взгляды старой школы unix-way.На самом деле, консерватизм и "старая школа" несовместимы с unix-way. Потому что unix-way предполагает постоянное стремление к простоте и прозрачности, а "старая школа" отрицает любые изменения.
> Александр Ларсон (Alexander Larsson), активный разработчик GNOME и мантейнер таких проектов, как Nautilus, Gnome-vfs и Dia
>причем в случае, если вывод осуществляется в терминал или принимающая команда не поддерживает на входе объекты, данные будут переданы в текстовой форме.имеет право на жизнь только в том случае, если в указанной ситуации будут вести себя также, как и без этих нововведений.
зыж
а для того, чтобы выдавал "данные будут переданы в текстовой форме" достаточно ввести параметр командной строки типа --gvariants и пусть выводит:
<{'pid': <uint32 1>, 'ppid': <uint32 0>,....................
Сами же утилиты должны собираться как с glib, так и без.
Вот тогда да, можно юзать.
>Раздумывая над способами модернизации командной строки UNIX, Александр Ларсон (Alexander Larsson), активный разработчик GNOME и мантейнер таких проектов, как Nautilus, Gnome-vfs и Dia, предложил в своем блоге новый способ объединения команд с помощью пайпов, основная идея которого заключается в передаче через канал не простых потоков неструктурированных данных, а объектов, представленных в бинарной форме.Уважаемый Александр Ларсон, ИДИТЕ НАХРЕН И ПОТТЕРИНГА С СОБОЙ ЗАБЕРИТЕ. ВЫ ПРЕВРАТИЛИ ЛИНУКС-ДЕСКТОП В КАКОЕ-ТО ГАВНО, ОСТАВЬТЕ МНЕ ХОТЯ БЫ КОММАНДНУЮ СТРОКУ.
С уважением, анонимный посетитель опеннета.
Похоже, Элоп - не единственный диверсант Мекрозофта.
Корпорация Зла в работе: то матьки в ядре, то звук по сети, то бежапашная загрузка. Вот и до командной строки добрались...
> dps | dfilter euid \< 1000 | dsort rss | dhead 4 | dtable pid user rss vsize cmdlineЭто вместо одного ps?! Не-не, Дэвид Блэйн! Сами кушайте такое.
Кстати а чем им d-bus не понравился? Ах, NIH укусил? :)
А потому, что он не позволяет
>расширить границы для входа на новую ступень эволюции
>и начать процесс проникновения в альтернативные области на новом
>не доступном до сего момента уровне.например
>> dps | dfilter euid \< 1000 | dsort rss | dhead 4 | dtable pid user rss vsize cmdline
> Это вместо одного ps?!
> Не-не, Дэвид Блэйн! Сами кушайте такое.Как раз сейчас очередной раз пинал ps после очередной раз упавшего у юзера pulseaudio, паралледьно поглядывал в топик, наткнулся на цитату и невольно вырвалось:
Во бл*дь!
Не надо.
Сколько "не нужно" сразу в одном посте.
Не пускайте [s]траву по венам[/s] объекты по конвейеру.
Мало кто знает, что такое strike, но я плюсану.
Если долго сидеть под форточками, можно весь мозг отморозить и заработать ООП головного мозга, осложненное типизацией ЦНС.
А сколько сколько там всего было разработчиков гнома? :)
>Один из разработчиков GNOME предложил новую реализацию неименованных каналовЭтому заголовку остро не хватает продолжения: "... но его послали на х*й".
>>Один из разработчиков GNOME предложил новую реализацию
> Этому заголовку остро не хватает продолжения: "... но его послали на х*й".Если это будет прямо там навирху, то сра^Wобсуждение не задастся. //Хотя после "..." -- можно, никто ж не читает.
> а объектов, представленных в бинарной формеИ новости на opennet: в coreutils версии x.xx в очередной раз сломана бинарная совместимость :)
расскажите же ему уже про grep, sed, awk, tr и ещё кучу утилит.кажется, портеринг распространяет вредные заразные бациллы.
dps | dfilter euid \< 1000 | dsort rss | dhead 4 | dtable pid user rss vsize cmdlineО да, я всегда мечтал вводить в консоли шириной в 500 символов строчки две-три, просто чтобы увидеть список процессов.
Что так мало-то?
Не, пусть будет, но как просто дополнительное средство, а не как замена тому, что уже есть. Хотя я бы предпочёл что-то вроде:
SELECT pid, user, rss, vsize, cmdline FROM ps WHERE euid < 1000 ORDER BY rss LIMIT 4;
> Хотя я бы предпочёл что-то вродет-с-с-с! накаркаешь ещё.
Как бы есть alias.
> SELECT pid, user, rss, vsize, cmdline FROM ps WHERE euid < 1000
> ORDER BY rss LIMIT 4;Так это же WMI
WMI была бы удобной вещью, если бы она поддерживалась везде, хотя бы самой MS в своих продуктах. А как идея мне, например, нравится.
Простите, если чукча не читатель. Чтобы реализовать такой подход надо:
1. Отдающий процесс реализут струтуризацию
2. Принимающего процесса реализует структуризацию
3. В случае смены Правил структуризация они одновременно поменять реализацию
4. Маловероятно, что предложенная сейчас стуктуризация будет удовлетворять все потребности в будущем.
> Раздумывая над способами модернизации командной строки UNIX,
> Александр Ларсон (Alexander Larsson) . . .. . . и тут подсел к нему Леннарт: "Чё Санёк, всё раздумываешь? Давай лудше дунем, мне голландские линуксоиды свои идеи прислали, грибы мексиканских линуксоидов и рядом не росли 8-)"
Давно пора. Это было нужно сделать ещё вчера. Я об этом уже не один год мечтал. Бинарные объекты - большая скорость, легче парсить и гораздо выше скорость обработки данных. А также возможность передавать не только текст, или плоский бинарный выхлоп, но и аудио, видео и даже ссылку на нужный метод нужного объекта. Программы можно будет соединять как конструктор, система станет намного гибче. Тот же LibreOffice можно будет разобрать на множество маленьких несложных приложений, объединённых общей объектной моделью. А для совместимости оставить старый текстовый выхлоп. Если идею тесно интегрировать ещё и с системной шиной D-Bus, мы получим ОС, которой по мощи не будет равных.
ВЫ-ДЫ-ХАЙ!
а ничего, что со времён вашего unix-way появились разделяемые библиотеки?
Мне например запускать внешнюю программу через popen и парсить её выход
никак не прикалывает. А тут универсальный api -- хоть какая-то связь между
зоопарком языков программирования, раз уж CLS не осилили.
Что за ахинея? Мало надо изучать как сам софт настроить, так ещё и программером становится, для облегчения ежедневных задач.
какие ещё ежедневные задачи? С предложенным подходом фильтрация становится тривиальной, а других задач и нет.
А вот попробуй автоматизировать какой-нибудь git, и сразу поймёшь как убог текстовый вывод.
Любых, мля, задач что раньше делались скриптами обычными щеловскими, с использованием обычных утилей - принимающих и выдающих текст, а не бинарные блобы. Допустим отпарсить любую фигню как надо и кинуть на другой сервер. А теперь всякие умники вон какой-то "универсальный апи" выдумывают, дальше обмажутся объектами как в павершеле. И наступит счастье.
чем тебе объекты как PS не нравятся? да, реализация убога, но идея отличная.
>Допустим отпарсить любую фигню как надо и кинуть на другой сервер.Бинарные блобы не помешают, а помогут -- парсить легче.
Ничего отличного, после общения с пауршелом, не вижу в данной идеи. И бинарики мне никак не помогут парсить. Мне надо сделать какую-то вещь. Я на месте пускаю несколько команд через пайпы и смотрю вывод - правильно сделал я или нет. Потом добавляю ещё пару команд. Зачем лишнее барахло в виде бинариков? Или для улучшения жизни мне все входные данные для скриптов (включая логи, вывод команд, etc) надо бинарные, дабы почувствовать всю мощь новых утилит?
Да да идея хорошая, давайте ещё парочку другую протоколов новых придумаем, а это эти ретрограды так достали уже!
Замечательная идея, проблема с переходом (ведь по любому будут пакости с самописными скриптами), да и разработчикам переделывать половину утилит на поддержку и тп (всё-таки поддержка двух режимов).
Не пойму зачем тут PowerShell приплели в сравнении. (в Win это намного лучше "стандартной консоли", без вариантов - т.к. таковых просто нет)
Бедный Туомо. Всегда находится какой-нибудь идиот, который выставит идеи Туомо пятилетней давности как инновацию, да ещё и реализует так, что оному захочется со стыда умереть на месте
