> Ваша честь, я протестую!:) "Аналогичная ФС без многопоточности" - бессмысленное сочетание слов. Многопоточность слишком сильно влияет на организацию ФС (и vfs, и os, и физического расклада), чтобы считать возможным употребление слова "аналогичная".

Бессмысленное, зато забавное. Ладно, не аналогичная, просто ФС без многопоточности, но родная для данной ОС. (FAT не предлагать! :) )

> Изменение, не закрепленное в стандарте, - норма жизни. Стандарты появляются на основе уже сделанных изменений. Просто нужно вовремя переводить полезные изменения в открытые стандарты. Или Вы серьезно думаете, что стандарты появляются на пустом месте?

А вы не согласны, что стандарты делают жизнь легче? (Это чтобы не приписывали мне веру про появление стандартов из ничего). :)

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

> Вообще, я всегда считал себя БОЛЬШИМ любителем стандартов. Оказалось, есть фанаты и покруче меня...:)

Ну смайлик там стоял. К тому же это не слишком точная цитата не помню откуда.

2svu
> Про 5% задач - это Вы где померяли?...
См. в этом треде.

>Если это экспертная оценка - можно привести список экспертов?
См. там же.
Т.е. совсем безответственная оценка от балды :) А если серьезно, то не думаю, что получится провести колько нибудь качественную оценку в данном вопросе.

> И интерфейсы своих прог (особенно - либов) пытаюсь "поднимать" насколько можно.
Можно подробнее с этого места? Действительно интересно. Вполне возможно что у меня с вами расхождение в определении терминов "абстракция", высокоууровневый интерфейс. Приведите пример, плс.

> И задача "отбить бабки за новый проц" среди них не значилась.
Ну значит не все основные задачи были рассмотрены - вывод то, что было обсуждено выше не является объективной оценкой, а несет сильно субъективный характер.

> Помнится мне, потоки в файлах на Маке появились, когда ресурсы были еще достаточно...
Как подправил Irsi 2 потока. Данные и атрибуты. Соглашусь в том, что реализация красива, это факт. Но также вспоминаются "забавные проблемы" когда файл с Мака по сетке или иным способом бросаем в Windows и затем тащим обратно и все... Звиздец файлу :( Приходилось эти потоки паковать и только так таскать между машинками.

> Кстати, про осовремениванье десктопа - многопоточные файлы могут
> помочь и тут. Посмотрите на то, сколько файлов несет в себе
> инсталлированое приложение для гнома...
Перечисленные вами проблемы можно решить и из User Space. А вот проблем может доставить достаточно из-за отсутствия обратной совместимости. Или как такие поточные файлы править например в консоли если их вид не стандартизирован (возмем к примеру текстовые конф. файлы. Несмотря на то, что их формат не стандартизирован и у каждой программы свой их правка не составляет большой сложности).

Убожество убожеству рознь. А по мне виндовс отличная ось и непонятно что ее все так ругают. Да может немного подглючивает - это бывает, а кто не глючит. У меня нормально отстроенная винда годами стоит. Перестановливаю раз в год и то для профилактики.

Выскажу свое мнение по поводу жаркой дискусии об операционных системах. К сожалению в них разбираюсь слабо. Использую только в качестве пользователя. Вот для примера мне один знакомый сказал что вот он показал людям линукс показал OpenOffice.org и т.д. и люди начали работать под линуксом и что на его практике не было случая перехода с линукса опять на виндовс. Так вот я перешел обратно на с линукса виндовс, вкрадце объясню почему.

Первая причина - не главная. Отсутсвие софта которым привык пользоваться. Можно в принципе заменить чем нибудь.

Причина вторая - основная. Дастало. Что ни дистрибутив то концерт бесплатный. Дистрибутивы абсолютно не совместимы. Если вышла версия дистрибутива х.х.х, то дистрибутив х+1.х.х как небо от земли отличается от х.х.х. Причем зачастую проги с х+1.х.х на х.х.х не поставить, требуется видели переапгрейдить кучу библиотек.

Плюс проблема с оборудованием. Ну почему каждый дистрибутив мою звуковуху либо видит по разному либо вообще отказывается работать, хотя модули есть.

Дистрибутивы - ужас какой-то. Дебиан (Вудди) 8700 пакетов, а работать несчем. Зачем спрашивается.

Единственный по моему дистряб с человеческим лицом (созданый для пользователя) ALTLinux. Но там тоже хватает проблем.

Такое ощущение что этот бардак, который творится в Линукс сообществе никогда не кончится, поэтому ну это все навиг надо наконец привыкать жить спокойно.

Последний глюк который меня убил. Линукс не смог прочитать компакт диск и упал.

2anonymous (*) (2003-02-09 11:17:10.3):

А это тут причем? В новости Linux поставлен только как примечание и ни малейшего отношения к нему новость не имеет => этот возглас - offtopic.

2svu:

Довольно давно читаю эти комментарии, и должен сказать вы меня практически перетащили на свою сторону с противоположной. В принципе мысль о потоках если рассматривать desktop или рабочую станцию это просто дело привычки. Ну подожду я в 2 раза дольше, пока откроются не 2 потока, а 2 файла и наоборот - подожду открытия 2-х поточного файла, когда в староидейной фс это будет быстрее. Так, само по себе это вносит некоторое упорядочивание в бесконечные .desktop, .png и тд. Т.е. можно будет иметь всего один файл после операции в mozilla (Сохранить как, полностью). Это безусловно плюс. И большой. Есть определенный минус - то что потоки безусловно будут либо теряться, либо с ними будет происходить какая-то гадость. Т.е. ограничиваться записью только потока 0 нельзя! Иначе просто при попытке перенести на дискете этот замечательный .html_complete файл я получу автоматом .html! А все свалят на mozilla! :-)

Т.е. должны практически сразу поменяться общесистемные программы, работающие с файлами типа nautilus, konqueror, cp, mc и даже XNC! Далее, сразу же будет нужна поддержка многопоточности на всех файловых системах Linux. Этим может заниматься не конкретная фс, а более высокий уровень, по аналогии с UMSDOSFS, которая представляет собой просто FAT со скрытыми для Linux программ файлами.

Так можно будет хотя бы избежать потери потоков при копировании на дискету, которая размечена в FAT. Т.е. получается что можно пойти по стопам Win 95 с ее progra~1... :-), введя вместо потоков на неподдерживающей фс файлы вида 1.txt, 1.txt~1, 1.txt~2.... для каждого из потоков. Если этого или подобного не сделать, т.е. если эта система будет терять потоки, то мне она не нужна! Впрочем и вам наверняка тоже...

>Вот для примера мне один знакомый сказал что вот он показал людям
>линукс показал OpenOffice.org и т.д. и люди начали работать под >линуксом и что на его практике не было случая перехода с линукса опять на виндовс.

что то подозрительно знакомое :)


> Так вот я перешел обратно на с линукса виндовс, вкрадце объясню почему.

>Первая причина - не главная. Отсутсвие софта которым привык
>пользоваться. Можно в принципе заменить чем нибудь.

вот этим стоило заниматься.
подбирать нужный софт и делиться с другими этой информацией.
работа небольшая, но нужная сразу всем.



>Причина вторая - основная. Дастало. Что ни дистрибутив то концерт >бесплатный. Дистрибутивы абсолютно не совместимы.

Пора уже выбить большими буквами на воробъевых горах и прочих высотах - "Не прыгайте с дистра на дистр!!!"
В рамках _любого_ дистра можно добиться всего необходимого.
Все что надо, это войти в контакт с разработчиками и пользователями этого дистра и совместно быстро и эффективно решать все возникающие проблемы.
Вместо этого уже тысяный раз видим,как пользователь ставит n+1 дистр в котором опять изучает n+1 раз одни и те же примитивные вещи.
Времени и сил на продвижение вперед просто не остается. Глупость неимоверная.

>Если вышла версия <дистрибутива х.х.х, то дистрибутив х+1.х.х как >небо от земли отличается от х.х.х. Причем зачастую проги с х+1.х.х >на х.х.х не поставить, требуется видели переапгрейдить кучу библиотек.

Для решения этой проблемы есть:
1) apt-get dist-upgrade
2) apt-get install пакет --rebuild

В виндос поступают проще. Каждая прога тянет за собой все используемые библиотеки. По моему это хуже (но у них и выход другого нет).



>Плюс проблема с оборудованием. Ну почему каждый дистрибутив мою
>звуковуху либо видит по разному либо вообще отказывается работать,
>хотя модули есть.

Значит столько изменений в драйверах. На моей практике ни одна звуковая карточка не преподносила таких сюрпризов. Максимум - переименовывались модули или depmod -a надо было руками сделать.

>Дистрибутивы - ужас какой-то. Дебиан (Вудди) 8700 пакетов, а работать
>несчем. Зачем спрашивается.
Значит, этот дистр не для вас. Есть просто море народу, которые уверены, что в Вуди все есть.

>Единственный по моему дистряб с человеческим лицом (созданый для
>пользователя) ALTLinux. Но там тоже хватает проблем.

Проблемы надо решать. Отличие от виндовс - с линуксом у вас есть такая возможность.

>Такое ощущение что этот бардак, который творится в Линукс сообществе
>никогда не кончится, поэтому ну это все навиг надо наконец привыкать
>жить спокойно.

демократия всегда смахивает на бардак. Не зря же говорят, что при Сталине был порядок...


>Последний глюк который меня убил. Линукс не смог прочитать компакт
>диск и упал.

Скорее не линукс, а сдром шину подвесил. Таков Ide в действии. Правда в виндовс с тем же сдромом еще хуже.

>У меня нормально отстроенная винда годами стоит. Перестановливаю раз в
>год и то для профилактики.

В профилактории ничего не говорили про невозможность стоять _годами_, и одновременно переустанавливаться раз в _год_?
:)

2AVL2 (*) (2003-02-09 14:35:57.794):

а у него винда стоит "одними годами"! :-)

Конечно Win98 может стоять и год и 2 и 4. Но это не освобождает от обязанности бред не нести! :-)

2svu

Очнитесь, о чем вы говоpите? Вы _выдyмываете_ (даже не двигаете) pеволюцию, котоpая отвеpгает пpинципы, yспешно сyществyющие в течение лет 40-ка. Hапpашивается вопpос: ваши пpедложения комy-нибyдь pеально нyжны? Я полагаю, что нет, ведь иначе вы -- гений, котоpый действительно пеpвый до этого додyмался! Те пpимеpы использования и пpименения, котоpые вы пpиводите, несyт лишь хаос как в пpикладных, так и в системных плоскостях. А этапы вашей pеволюции yтопичны. Hy кто ее бyдет свеpшать, если никомy не нyжны pезyльтаты (даже вам)?

P.S. Если вы не менеджеp, то пожалyй вам стоит пеpеквалифициpоваться. Подобные аpгyменты позволяют им yспешно пyдpить мозги и заpабатывать на этом пpиличные деньги.

Weaver.

А сколько лет многопоточности в НТФС ?

Открываю Офис. Фичи писать автора, иконки в другие потоки
не нахожу. В Ыкспрорере - тоже. В Кореле, Винампе, Делфях
и т.д. тоже. Поиск по каким-либо потокам тоже отсутствует.
Куда простому юзеру тыкнуть МЫШКОЙ, чтоб открыть другой
поток ?
Или это - такая очень "нужная" фича, что даже М$
за несколько лет не сумела придумать в какую прогу ее
пристроить ?

Кстати, в rox (точнее в risc) есть некий аналог многопоточного файла - appsdir.
В одной дирке лежит иконка, xml c описанием, дирка с хелпом и запускающий скрипт.
Всегда все под рукой.

Плюс - иконка может быть линком к примеру на /usr/share/icons/xxx, как и Хелп на /usr/share/doc/xxx и все остальное. Скорость работы отличная. DnD и все функции работают. Совместимость полная. Возможно такое с многопоточными файлами?

Кто хочет посмотреть на _реализоыванный_ вариант - apt-get install rox и смотреть им в /usr/apps - наутилус отдыхает, хотя должен вроде бы работать быстрее.

Виноват, можно точнее указать - где в это треде смотреть про 5%?:) Вот про то, что не получится привести оценку - верю почти сразу.

Ну, особо "подробнее", наверное, сложно - большинство написанного мной кода принадлежит моей компании:). Но как слабо относящийся к делу пример (извините, наверное, некоторым из завсегдатаев уже, наверное, надоел) - выделение удобного api для работы с xkb в libxklavier. Не зависящей от тулкита. Просто поднятие достаточно низкоуровневого xkb api (особенно в разделе работы с их файлами конфигурации) на чуть более высокий уровень (группировка часто встречающихся последовательностей вызовов, параметров и пр.).

Ну ладно, будем считать, что одной их ПЕРВОЗАДАЧ программной и аппаратной индустрий является зарабатывание денег. На этом программном заявлении можно закрыть обсуждение финансовой стороны вопроса:)

Да, на Маках было 2 потока - именно потому, что ресурсы были дороги. Но они там были. И к селу, и к городу. Да, интерфейс с однопоточными ОС был плохо продуман - но это же не повод ставить крест на идее как таковой, правда?

Опять 5^2! Да, это все можно делать из user space. Но единое для всех api на уровне vfs было бы намного лучше. И производительнее. И концептуально как-то целостнее - поддерживать потоки на всех уровнях - от физической раскладки fs - в vfs и далее через syscalls - к приложениям.

Поймите меня правильно, я не ратую за немедленную переделку уровня vfs имеющихся ОС в сторону многопоточности. Мне просто кажется, что если бы это было сделано (разумно, подумав обо всех последствиях и т.д.), есть некий шанс, что можно было получить от этого технологический выигрыш. И считать тему "закрытой" только потому, что некий набор mainstream os (включая opensource) не поддерживают этой функции - преждевременно. И даже то, что ntfs не использует эту функцию в полной мере - еще не говорит о бессмысленности ее. Для microsoft вопрос совместимость со "стариной" всегда был очень болезненным...

Ой, оказывается, я - хороший агитатор:)

Да, для многопоточных fs вопрос интерфейсов с однопоточным миром - сложный. Тут уже про проблемы с Маками жаловались. Но это же не повод выкидывать идею на свалку истории:)

2all Театр начинается с вешалки. То-есть, с удобств, а не с задов сцены. Обидно, что отдельные умные люди оценивают вещи не по востребованности обществом, а по безотносительным параметрам.

Да я ничего не выдумываю. Я просто не хочу называть живого человека трупом. А Вы считаете, что он труп. Вот и вся разница:)

А все-таки, как Вы думаете - если бы nt создавали сразу ТОЛЬКО для ntfs и без необходимости выполнять старые приложения - многопоточность ntfs была бы востребована или нет?

Не, я не менеджер. И не очень я их люблю:)

Я вообщем-то в целом, про оценку NT. :-)

Потоки - не для пользователя. Они, в первую очередь - для application programmer-а. Так что - никаких кликов мышкой:) Кроме того, все вышеуказанные приложения должны работать и на fat - это бремя совместимости.

Да, на всякий случай - Вы помните, что самое существенное, чем работа с ntfs отличается в експлорере от работы с fat - это установка прав доступа? Вы помните, что это реализовано на потоках? Есть еще установка компрессии, но это, вроде, к потокам отношения не имеет.

а в xfs?
Насколько я не в курсе, квоты и acl лежат в структуре fs.
Какой смысл для хранения фиксированных структур типа иконка, автор, описание, квоты, acl делать многопоточность вместо введения расширенных атрибутов файла?
NT не может с одной только FAT разобраться? а как в линуксе с ее десятками ФС разобраться с совместимостью?

Да и безо всяких FAT совместимости со старым софтом будет дико трудно добиться. А без этого софта виндовс вообще никому не нужна.

2svu:

Как агитатор явно лучше Irsi, от которого меня уже давно тошнит. Не потому, что идеи дурацкие, а потому что зациклен на мысли "Linux говно" и продвигает ее всеми доступными средствами.

Наверно от многопоточных файлов в ReiserFS не повредит никому. Но прежде чем вводить эту многопоточность нужно очень хорошо все продумать... Может быть сперва ее ввести в user-space, а затем переместить в kernel.

И потом, меня до сих пор волнует вопрос - все ли знают, что в NTFS есть жесткие ссылки (и нет symbolic), а вот где они еще, кроме Far'а "используются"? ("используются", т.к. в Far'е они только проставляются). Не станет ли эта многопоточность в NTFS такой же фичей Far'a? :-)

2svu. Разъясни, плс, вопросы форматов и стандартизации этой многопоточной FS. А то непонятно несколько аспектов.

С ACL, или доп. атрибуты у Macintosh это понятно - системные фишки которые реализованы и имеют четкий API, а как быть с "произвольными" форматами? К примеру в своей программе реализовал конфиг для хранения разной лабуды с исп. многопоточности. Как остальные приложения разберутся что, где и как достать/положить? Подозреваю, что будут юзать мою же либу с моим же API. Тогда в чем выгода от многопоточности?

2 svu:
>И даже то, что ntfs не использует эту функцию в полной мере - еще не
>говорит о бессмысленности ее
Ага. Изобрели фичу, которой никто, включая производителя, не
нашел применения за 8 лет (или больше ?). Что еще может
говорить о бессмысленности ?
О совместимости. Лет 6 назад у меня на одном компе была Вынь95 и НТ.
Забавно, но НТя не видела ФАТ32, а Вынь95 не видела НТФС. И это -
поделия одной конторы ! И кто мешал тогда НТе использовать
многопоточность в полной мере ? Ведь на совместимость с ФАТ она уже
почти забила.

Вдогоку о совместимости.
Если у файла несколько потоков - работай с ними,
если один поток - работай с одним, если это ФАТ -
считай что у всех файлов один поток.
Это сложно реализовать? За столько-то лет.
Особенно если эта фича так остро необходима. ;-)

> Если у файла несколько потоков - работай с ними,
> если один поток - работай с одним, если это ФАТ -
> считай что у всех файлов один поток.
Да ну??? Таким образом ты получишь не нормальный файл, а полную байду. Почему? Просто. Есть мой многопоточный файл в потоке 1 - данные, в потоке 2 - метаданные. Данные представляют собой бинарный поток содержащий текст в определенной кодировке. Метаданные содержат доп. информацию о данных: кодировка, автор, ключевые слова, индексирующую таблицу и проч.

Теперь вопрос. Когда приложение получит единный поток 0, то где окажутся метаданные и данные? Как читающее приложение сможет получить только текст и не гемороиться со всем остальным? Предположим, что это текстовый редактор vi. Как ему "забить" на данные из 2 потока когда ОС смешала 1 и в 2 потоки в один 0?

Или прикажем ОС забыть метаданные и гнать в потоке 0 только данные? Как ОС распознает что где у меня в потоках записанно для такой операции?

Многопоточность не может реализовать обратной совместимости! Она может читать старые данные, но не может обеспечить нормальную работу однопоточных приложений.

Гемороя получается больше, значительно больше чем хочет нам показать господин svu. Может он сможет ответить на мои вопросы из предыдущего поста и из этого?

2green: "Где ты предлагаешь пранить права на доступ и другие свойства об'ектов, как они будет переживать рестарт системы (и сохраняться), почему это твое решение проще чем то что уже есть?"

Если кому-то ещё интересно... Посмотрел я это дело у Соломона и Руссиновича. Нуу, в NT всё наворочено. Там устройства - это объекты ядра, создаваемые драйверами. Драйвера загружает диспетчер PnP, основываясь на текущей конфигурации (которая в реестре хранится, помните "last known good configuration" при старте - это оно). Почему в NT отказались от отображения устройств на файловую систему ? Потому что подержку PnP и HotPlug устройств логичне делать так, как это и было сделано. Когда обнаруживается диспетчером PnP (или драйвером шины) новое устройство, то создаётся (в памяти) объект "драйвер", объект "устройство" (создаются они с помощью диспетчера объектов => у каждого свой ACL). Одно дело объект, другое дело информация о нём. Реализация устройств и способ хранения информации о них разнесены. В этом существенное отличие NT от того же Linux.

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

2 Korwin Такую проблему придется решать средствами ФС. Т.е. при копировании на ФАТ (к примеру)потоки с метаданными будут отброшены, останутся лишь потоки с данными. Когда данные отдаются с многопоточной ФС(МПФС - а че неплохое имя для мальчика:), то выдается не поток 0(все потоки в одном флаконе), а, скажем, только поток 1.

Думать надо еще над этим всем, а не рубить с плеча: то хня, а то зае-сь. Система нужна, идеи...

Таки чем этот вариант проще того что используется в Linux? Каким образом при использовании предложенной схеме проставлять ACLи на устройства, которые мы к системе еще не подключали, но хотим проставить до первого подключения (пока не забыли)?

(А то что "в памяти создается об'ект", ну так и в Linux он создаетяс когда появляется устройство, а когда не появляется - не создается. А ACL'и - отдельное свойство.)

И неужели это красивое решение? Для того чтобы посмотреть на эту "красоту" на пркатике надо только залезть в реестр. Это производит сильное впечатление (большая куча, если не сказать помойка). Только для того чтобы во всём этом разобраться надо прочесть не одну главу в msdn или в какой-нибудь толстой книге. Тут сразу хочется вспомнить Чехова с Оккамом :-)
А про то, как получать доступ к этим устройствам из приложений, вообще лучше и не говорить.

Блин, как-будто программеров в этом треде вообще нет.. Кто-нить задумывался КАК приложениям договориться о НАЗНАЧЕНИИ потоков? В НТ как я понял потоки просто имеют индексы.. Как приложение должно узнать что поток номер 1 это именно иконка, а не скажем ключевые слова для документа? Кто-то говорил "сохраняем веб-страницу в мозилле в файл, получаем file.html, который многопоточный и содержит все картинки/стили на которые ссылается этот файл". Как потом приложению открывающему многопоточный file.html выяснить что картинка movie.mpg на которую ссылается 0-й поток file.html лежит в потоке номер 47? Заводить свою "файловую систему" в специальном потоке чтобы указать какой поток какое назначение имеет? А не слишком ли это накладно - если просто пользоваться реальной однопоточной FS и все? Если все храним в потоках и заводим свою "файловую систему" - то получается что юзер не сможет например вытащить movie.mpg для личных нужд, и тем более удалить (допустим чтобы размер файла уменьшить для пересылки его по почте) из многопоточного файла этот поток (ведь индексы ПОПЛЫВУТ и все псевдофайловая система пойдет коту под хвост!). При хранении потоков наверно (в НТ уж скорее всего точно) не запоминается время создания/обращения к потоку.. В общем у меня такое впечатление что потоки сделаны microsoft'ом только для реализации ACL'ов и шифрованных файлов, и никому больше ни для чего (включая МС) они не нужны - что это полностью никчемная возможность для ПРИКЛАДНОГО ПО (для системного - да, вещь полезная - но только если пользуется ими только софт от одного вендора - вендора ОС).. И слава всем святым что пограммисты под винду этими потоками не начали пользоваться - юзеру с ними будет очень тяжело!

PS: что касается extended attributes в linux-2.5: никто не в курсе случаем -они тоже будут адресоваться только индексом? Или произвольным целым числом? Или (самое приятное для программиста) строками? Уж думаю учтут кривость виндов и уйдут от тупых индексов.

sco-killer! Мне кажется ты один из тех кто сидит на Advanced server-e и который думает что "Если добавить на этот сервак еще гига 4 RAM то все прекрасно продолжит рабботать и дальше". Кернел у тебя 2.4.18-3e ? Оригинальный от RedHatAS2.1. Я его испытал одним из первых - тот продемонстрировал бысрый freeze :) Пришлось его выкинуть.

Ничего подобного насчет драйверов для health мониторинга от Compaq. Собираются (автоматически при перезагрузке!) для любого кернела, если есть исходники конечно.

Насчет теории в 64G ты прав. Я уже понял как все на практике :) И сказки про чудесную производительность sun слушать тоже не хочу. Конкретные тесты не проводили. Но есть идея что новый Compaq будет как минимум в 2 раза быстрее. Хороший пример - импорт одной и той же базы иден на Sun 26 часов, на Compaq 2 часа 30 мин.

2green: Как проставить ACL - всё полностью на совести драйвера. И где хранить ACL, чтобы он мог пережить перезагрузку - тоже. В случае файла - хранится в ФС, в случае устройств, думаю, где-нибудь в реестре.

"Проставлять ACLи на устройства, которые мы к системе еще не подключали, но хотим проставить до первого подключения (пока не забыли)" Это плохая идея. Ведь только драйвер знает, какие есть атрибуты у устройства, соответственно с помощью него только и можно эти атрибуты поставить. Понимаю, что этот подход кажется вывернутым наизнанку. Это не кажется, так оно и есть. Устройство в метафизическом плане - и есть драйвер ;) Можно провести аналогие с ОО проектированием - только через интерфейс можно изменить внутреннее состояние объекта. Так что прежде чем что-то с устройством делать, надо поставить его драйвер, а потом сказать ему, как конфигурировать устройство.

Мне вот что интересно, а как в Linux реализуют HotPlug и PnP ? Ведь как-то реализуют.

>PS: что касается extended attributes в linux-2.5: никто не в курсе
>случаем -они тоже будут адресоваться только индексом? Или
>произвольным целым числом? Или (самое приятное для программиста)
>строками? Уж думаю учтут кривость виндов и уйдут от тупых индексов.

http://acl.bestbits.at/cgi-man/getxattr.2

> Блин, как-будто программеров в этом треде вообще нет.. Кто-нить задумывался КАК приложениям договориться о НАЗНАЧЕНИИ потоков?

Вы программер или кодер? Это детали реализации. Уровня приложения. Если приложение _нуждается_ в потоках, то наверное оно знает как их использовать.

Вопрос был в том нужно ли вносить изменения в ФС или обеспечивать доп.возможности через либы (или вообще это все фигня и приложений, которым это реально нужно не существует).

Оккам говорил "не умножай сущности без необходимости". Не лезь в реестр без необходимости ;) Реестр не предназначен для того, чтобы в нём копались regedit-ом вообще-то. Совсем наоборот. В реестр должны лезть только программы/компоненты системы.

Отдельные разделы реестра (связанные с user mode, в частности с первой сырой реализацией COM под windows95) организованы из рук вон плохо. Но не надо смешивать организационные моменты с архитектурой системы. Ядро тут не виновато ;) А в том, что некое специализированное хранилище для настроек необходимо, у меня сомнений нет, и даже в Lixnux все к этому идёт, то есть даже уже пришло для user mode (gconf в GNOME, в KDE не помню что, но тоже есть).

Хммм. Но ведь я же в реестр не от хорошей жизни лазил. Разве я виноват что у меня небыло другого способа поменять поведение драйвера?
Про некий единый подход к хранению настроек - я согласен.
Что касается всего остального, то тут имхо плохая продуманность системы как целого налицо. От этого и реестр появляется и бардак в нём ;-)
Про ядро. Оно, ведь, не может само по себе существовать. Вот предложите как можно решать задачи, о которых идёт речь, как-то более элегантно (без vfs и реестра).

   Вы  программер  или  кодер?  Это детали реализации. Уровня приложения.
   Если  приложение  _нуждается_  в потоках, то наверное оно знает как их
   использовать.
То есть интероперабельность Вас что-ли вообще не интересует?
В случае с линуксом (спасибо asaw)  у атрибутов есть имена - что автоматически
снимает все вопросы об интероперабельности. В случае виндов как я понял
программист имеет дело только с индексами. Что усложняет задачи программистов
и пользователей крайне сильно, и делает потоки-по-МСовски ненужной (как всегда)
поделкой. Нафига спрашивается ОС (ядро) если она ничего не облегчает
программисту?

2asaw: Спасибо за ссылку. А именно такие EA будут в linux-2.5 или что-то другое?

Для anonymous (*) (2003-02-06 19:41:19.248)! >где таких придурков как этот nazarov_serg303 берут, наверное в >детском саду чукотском... он типа крутой админ, ораклы всякие >компаки... а то что ядру можно опцию передать или упаси господи его >перекомпилировать - впервые читает здесь. что такое rpm для него >неразрешимая задача... да гнать таких админов надо... любой >приходящий чел за пару часов и 200 баксов настроит все по уму и >выгоднее будет намного чем платить деньги человеку который на >брендовом железе и боевой базе изучает какие бывают у ядра опции >загрузки...

Где это я назвался крутым админом? И попрошу без оскорблений :) Так вот я тут(на конференции) как раз затем, чтобы выяснить что сделает "любой приходящий за 200 баксов", чтобы мой оракл работал на этом сервере и не глючил :) Да вот что-то нет ответа... Создается впечатление, что все сговорились(хотят 200 баксов заиметь :) и не выдают страшную тайну как же пустить (хоть какой-нибудь!) кернел-64G чтоб он не замерзал и не глючил на моем сервачке...

SCO-KILLER! Твой пример не считается! у тебя менее 4G ram и кернел скорее всего видит только до 4G! У меня мой сервачек в такой конфигугации прекрасно работает.

Да и насчет производительности sun сказки надоели. Этот compaq кажется будет работать как минимум в 2 раза быстрее sun. Конкретные реальные тесты нашей базы не проводили. Но например полный импорт одной и той же базы на sun идет 26 часов, на compaq 2 часа 30 мин.

nazarov_serg303

> То есть интероперабельность Вас что-ли вообще не интересует?

Интересует и именно поэтому я лично против потоков. Т.к. вместо простого файла единообразно используемого всеми программами, появятся новые сущности "файл для nautilus'а", "файл для хрен знает чего" и т.п. Хотя при наличии документации (ну или хотя бы хэдеров) можно будет разобраться что где лежит, но проблем будет ...

> В случае с линуксом (спасибо asaw) у атрибутов есть имена - что автоматически снимает все вопросы об интероперабельности.

Ни хрена это не снимает. У атрибута имя "XYZ", а там дрова. Чем отличается "video/mpeg" от #define NS_VIDEOSTREAM 4566 ? Кто будет проверять соответствие меток данным? ФС.

> В случае виндов как я понял программист имеет дело только с индексами. Что усложняет задачи программистов и пользователей крайне сильно, и делает потоки-по-МСовски ненужной (как всегда) поделкой. Нафига спрашивается ОС (ядро) если она ничего не облегчает программисту?

Не в курсах.

Следует читать

Кто будет проверять соответствие меток данным? ФС????

про многопоточность файлов

А может быть, перевести проблему поточности файлов на другой уровень? допустим, у нас есть streamedfs, которая проецирует {xfs,ext3fs,reiserfs,...} таким образом, что:

* для каждого файла конкретной ФС есть ссылка на файл:поток в streamedfs * и наоборот, для каждого многопоточного файла известны все его пути в конкретных ФС'ах.

Инструментарий -- можно сделать через отдельные вызовы, а можно и примаунтить streamedfs в /streamed и работать через обычные вызовы (open('/streamed/home/vasya/config', 'rt'). Ну и /etc/fstab.streamed в придачу.

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

ACLи эот НЕ внутреннее состояние об'екта ни в коем случае.

А PnP и Hotplug - как и у всех - воткнул железку, драйвер шины ее заметил, загрузил драйвер железки, драйвер железки зарегистрировал новое устройство. Все.

>А именно такие EA будут в linux-2.5 или что-то другое?
Вообще-то в 2.5 они уже есть, а будут они в 2.6 ;-) Что касается API, то, AFAIK, он posix'ом гарантируется.

Если не боишься запачкать руки - тебе нужно убедиться что к твоему ядру приложены все highmem -related фиксы, которые необходимы. Что у тебя стоит последняя версия Highmem-IO патча. ну там всякие highmem-pte и так уже наверное есть. Оттуда и начинать плясать.

А какие проблемы ? Если с драйвером идёт GUI, с помощью которого можно дёргать настройки, берёшь его. Если не идёт, но настройки документированы, то увы и ах - берёшь и лезешь regedit-ом.

"Что касается всего остального, то тут имхо плохая продуманность системы как целого налицо" Как целого - я и не говорю, что хорошо всё продумано. У windows 2000 был очень тернистый путь, тяжёлое наследие win3.1 и win95 (подчёркиваю: обратная совместимость реализована в user mode). Дэйв Катлер, как говорится, за Крейга Брокшмидта (разработчик OLE2) не отвечает ;) Впрочем, у Linux тоже был тернистый путь, и не будем об этом, это отдельный длинный разговор ;)

"Про ядро. Оно, ведь, не может само по себе существовать. Вот предложите как можно решать задачи, о которых идёт речь, как-то более элегантно (без vfs и реестра)." Не понял. При чём тут vfs - раз. Почему надо отказаться от реестра, мы ведь вроде пришли к согласию, что реестр - хорошая штука ?

Да в том-то и дело, что придется переписывать _все_ приложения. Текстовый редактор для редакции n потока, куда кто-то записал настройки, видеоплейер для просмотра m потока, редактор иконок для k потока... Самое смешное настанет тогда, когда потребуется запустить выполняемый файл из n+1 потока.

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

2green:

"А PnP и Hotplug - как и у всех - воткнул железку, драйвер шины ее заметил, загрузил драйвер железки, драйвер железки зарегистрировал новое устройство. Все" Файл в /dev, считается, уже создан со всеми правами ? ;) Теперь улавливаешь, почему в NT сделанно именно так, как есть ?

"Все--таки выставлять атрибуты заранее - идея не такая и плохая просто потому что мы заем что доступ у нас может быть на чтение и на запись. И все. (а какие еще другие виды доступа бывают?)."

Разные. У разных объектов - разные виды доступа. Если ты полезешь на вкладку security какого-нибудь принтера (а лучше там же в advanced), увидишь, что у принтера виды доступа есть: print, manage printers, manage documents, read permissions, change permissions, take ownership. Это не совпадает с видами доступа к файлу (sic!).

"ACLи эот НЕ внутреннее состояние об'екта ни в коем случае. "

Почему ? Проводя далее аналогию с ОО проектированием, что лучше: все классы объектов отнаследовать от самого общего класса, который имеет интерфейс для изменения ACL или у всех сделать открытыми структуры данных, чтобы кто угодно мог (грязными) руками изменять ACL объектов сам ? Первое по всем понятиям лучше ;) Инкапсуляция лучше. Ошибок меньше.

2yakuza

> Почему надо отказаться от реестра, мы ведь вроде пришли к согласию, что реестр - хорошая штука ?

Не расскажете как IIS пользуется этой хорошей штукой и что такое metabase? :)

"Не расскажете как IIS пользуется этой хорошей штукой и что такое metabase? :) "

??? Форум не для этого. http://www.intercon.ru/~dmitry/about.php - мои контакты.

>Не понял. При чём тут vfs - раз.
Ну как же? Например для доступа к устройствам и для назначения прав на доступ.

>Почему надо отказаться от реестра, мы ведь вроде пришли к
>согласию, что реестр - хорошая штука ?
Ну это опять же дело вкуса. Я не имел в виду именно реестр. Это могла-бы быть, скажем, библиотека для работы с настройками сохранёнными в xml-файлах. Вообще, когда делали GConf, было очень много споров на эту тему. И в конце концов, GConf имеет гораздо меньше недостатков присущих реестру виндавс (надёжность например).

>Почему ? Проводя далее аналогию с ОО проектированием, что лучше: все
>классы объектов отнаследовать от самого общего класса, который имеет
>интерфейс для изменения ACL или у всех сделать открытыми структуры
>данных, чтобы кто угодно мог (грязными) руками изменять ACL объектов
>сам ? Первое по всем понятиям лучше ;) Инкапсуляция лучше. Ошибок
>меньше.

Не путайте специализацию с инкапсуляцией. Это суть разные вещи. Что точно имелось в виду?