Виртуальная файловая система /proc предлагает новый подход к взаимодействию ядра Linux® и пользовательского пространства. В этой файловой системе содержатся виртуальные файлы, путем чтения и записи которых можно манипулировать структурами ядра. В отличие от обыкновенных файлов, их содержимое динамически генерируется ядром. Данная статья (http://www.ibm.com/developerworks/ru/library/l-proc/index.ht...) расскажет вам о виртуальной файловой системе /proc и покажет ее в действии.URL: http://www.ibm.com/developerworks/ru/library/l-proc/index.ht...
Новость: http://www.opennet.me/opennews/art.shtml?num=17194
Да, на сайте ibm статьи всегда качественные, но забойные.
Интересно, а зачем надо было делать это через файлы? Нельзя сделать проще? Или принципы не позволяют?
Нет, в то время у них просто не было cmake :)
>Интересно, а зачем надо было делать это через файлы? Нельзя сделать проще?
>Или принципы не позволяют?Куда проще файлов то?При нужде можно чуть ли не голыми руками с ними работать.Да и программно как-то не особо сложно.В чем проблемы?
Свет очка! Ты виндузятница?
>Свет очка! Ты виндузятница?Светочка не виндузятница, светочка - тролль.
Unix-way не постич Windows-mind
Ни кого не хотел обидеть.
Просто народ, кто пишет под винду уже давно не юзают ни пайпов ни StdIn/Out.
WinApi, MFC что ещё нужно виндопрограммеру для счастья. А! Условно бесплатный Visual Studio. :) ну или полностью беспланый masm, что бы знали что такое хорошо, а что такое плохо...
ну не дебилы?..
А нужны ли pipe и stdin/out в большинстве проектов? В большинстве случаев вместо создания нескольких программ, передающих информацию через pipe, можно сделать библиотеки компонентов, которые можно соединять не хуже процессов через pipe (и даже лучше, т. к. при передаче через pipe часто информация преобразовывается в текстовый формат, что может снизить быстродействие). И этот подход вполне применим практически под любой ОС. Раньше, возможно, не было динамически загружаемых библиотек и ООП, поэтому и писали программы, обменивающиеся через pipe, но есть ли в этом необходимость сейчас?
>А нужны ли pipe и stdin/out в большинстве проектов? В большинстве случаев
>вместо создания нескольких программ, передающих информацию через pipe, можно сделать библиотеки
>компонентов, которые можно соединять не хуже процессов через pipe (и даже
>лучше, т. к. при передаче через pipe часто информация преобразовывается в
>текстовый формат, что может снизить быстродействие). И этот подход вполне применим
>практически под любой ОС. Раньше, возможно, не было динамически загружаемых библиотек
>и ООП, поэтому и писали программы, обменивающиеся через pipe, но есть
>ли в этом необходимость сейчас?llehf
Свети нам, Свет очка!
Погугли быренько и расскажи нам, как это ООП и динамически загружаемые библиотеки могли существовать ДО Windows? И почему тупые *никсоиды, придумавшие такие продвинутые вещи, до сих пор используют pipe?
И отдельный трактат на тему быстродействия в судию, пожалуйста ;)
Да, грубость не есть хорошо...
Про философию пайпов стандартных вводов и выводов и иже с ними.
Собственно большинство автоматизации рутины можно делать средствами шелла не трогая руками компилятор именно благодаря архитектуре стандартного ввода вывода и канального взаимодействия между процессами. Во первых это кросплатформенно, а во вторых во истину открыто. Или наобортот. А есть ещё и в третьих и четвёртых. Но это философия...
Попробуйте автоматизацию в винде средствами консоли сделать. Да так, что бы, например, работало и в Win2000 (не нужно про старьё!) и в Server 2003. Например каталогизацию файлов, управление доступом, конфигурирование софта и прочее...
Только вот, слишком много используются скрипты в linux (по моему мнению). Конечно они полезны в нескольких случаях, но, наверное, не при загрузке системы. Что касается использования компилятора, это не так сложно, что лучше, зависит от конкретной ситуации. Но все-таки, наверное, лучше компоненты оформлять в виде библиотек, а не виде отдельных программ, т. к., если эти компоненты используются сложной системой, то удобней и проще будет вызвать функцию библиотеки или создать объект, чем запускать новый процесс с организацией ввода-вывода через stdin/out. К тому же, на основе таких библиотек можно просто создать и программы, взаимодействующие через pipe или что-то похожее (в частности, такие консольные программы могут быть удобны при тестировании библиотеки).
Этот спор мог бы быть вечным :)
Наверное хороша золотая середина, ведь API не может быть бесконечным (имеется ввиду огромное количество библиотек и функций в них, с особенность их вызова и межвзаимодействия). Майкрософт уже давно борится с этим, систематизируя сложные объекты в COM, а те в свою очередь доступны в .NET. Но простоты использования не добавляется. Лишь появилось поколение специалистов .NET. Умножение сущности без необходимости, ИМХО.
От чего то сложные вещи проще делать шэллом оставляя управление через консоль, т.к. знаешь, что отработает это одинаково хорошо как локально так и удалённо. Это ещё один плюс в пользу стандартного ввода и вывода правда, уже в терминале...