LINUX.ORG.RU

где таких придурков как этот nazarov_serg303 берут, наверное в детском саду чукотском... он типа крутой админ, ораклы всякие компаки... а то что ядру можно опцию передать или упаси господи его перекомпилировать - впервые читает здесь. что такое rpm для него неразрешимая задача... да гнать таких админов надо... любой приходящий чел за пару часов и 200 баксов настроит все по уму и выгоднее будет намного чем платить деньги человеку который на брендовом железе и боевой базе изучает какие бывают у ядра опции загрузки...

anonymous
()

2green: да ты что? другая система команд это не более 10-15% всех сложностей, которые подстерегают портера с одной архитектуры на другую...:))))
На счет альфы - компак распродает запасы фактически, а так... альфа снимается с производства... Грустно конечно...:(
По поводу исходников десятки - значительная часть их открыта и зовется дарвином...

2speer: я тебе не тестовая лаборатория... А то у тебя вопросики в стиле "докажи что ты не баран", а отвечать на подобные вопросы имхо бессмысленно...
Твой вопрос про rawfs в ntfs меня порадовал... Твой уровень осведомленности в FS неплохо демонстрирует (где-то немного больше абсолютного нуля...) Для начала рекомендую почитать классиков и понять откуда появилось понятие FS, как оно соотносится с понятием DB, какие тенденции в развитии FS наблюдается, попутно почитать про CODASIL...
Про "многопоточность" я неоднократно приводил примеры - ACL, ресурсы оболочек типа Gnome/KDE, небольшие БД (до нескольких гиг сумарно)... Читай что я посоветовал выше и все вопросы типа "зачем нужна многопоточность" отпадут как идиотские...:) Кратко говоря - многопоточность это просто еще один шаг на пути возращения в FS в лоно DB, откуда они собственно в свое время и отделились как отдельное направление по причине убогости ресурсов тогдашних машин...:)

Irsi
()

2speer
Ириска по-моему уже задолбался приводить преимушества многопоточности файловой системы.
Вспоминая его постинги годичной давности, помнится, аргумент был таков (как я его понял) - приложения могут читать не все треды в файле, а только некоторые из них. Типа, если нечто вроде блокнота пытается прочитать (и модифицировать) файл, сохраненный в ворде, то ему достаточно добраться до треда только с текстом, а на информацию о форматировании (которая, допустим, лежит в другом треде) забить. Такой подход позволяет работать с "документами" (в общем смысле) программам разных версий, например, дописывая version-specific информацию в отдельный тред. Насколько эта фича используется приложениями - не в курсе, но идея (если я ее правильно понял и передал) - хорошая, и трудно реализуемая в подходе "все есть файл, если не character, то уж block - точно"

geekkoo

anonymous
()
Ответ на: комментарий от Irsi

2irsi
Извини, конечно, но какое отношение ACL имеет к многопоточности? А по поводу "возращения в FS в лоно DB" почитай что-нибудь про PIC System, и у тебя самого отпадут очччень многие вопросы.
P.S. Насчет Compaq - нет уже такой фирмы, есть HP.
P.P.S. А насчет NTFS - круто, конечно, :-) но на практике...
P.P.P.S. "Не говорите мне, что надо делать, и я не скажу, куда Вам надо идти". (c) не мой.

sco-killer
()

2geekkoo: это одно из многих приимуществ...:)
Кстати подходу "все есть файл, если не character, то уж block - точно" абсолютно не противоречит. Считай что файл как бы состоит из нескольких, скажем для простоты пронумерованных "files lite", где один из этих облегченных файлов (тот что с номером 0) и есть обычный файл...
Обеденены они единым именем и соотвественно - единой записью в каталоги... Ну в техминах ext2 считайем что запись в каталоге может ссылаться не на одну i-node, а на несколько, номер i-node в списке это и есть номер потока грубо говоря...:) Это весьма упрощенный подход, но саму идею понять дает имхо...:)

Irsi
()

2sco-killer: YEES!!! Я ждал этого вопроса, а именно "какое отношение ACL имеет к многопоточности?", но правда не от тебя а от speer... А прав был тот ананимус, который на предыдущей страницы флейма сказал "Тому, кто первым перевел thread как "поток", надо поставить памятник. С табличкой "Плевать сюда"."
Кратко говоря - ACL в NTFS хранятся как отдельный поток. И это ОЧЕНЬ удобно, ибо если тебе захотелось слегка изменить структуру ACL, например добавить новый атрибут, тебе не надо менять ни драйвера FS, ни ядра - тебе достаточно соответствующим образом подправить код модуля acess managers... А вот тут мы подходим к вопросу "почему рулит микроядро" :))))

Irsi
()
Ответ на: комментарий от Irsi

2irsi
>Кратко говоря - ACL в NTFS хранятся как отдельный поток. И это ОЧЕНЬ удобно, ибо если тебе захотелось слегка изменить структуру ACL, например добавить новый атрибут, тебе не надо менять ни драйвера FS, ни ядра - тебе достаточно соответствующим образом подправить код модуля acess managers...
Удобство программисту - это, конечно, здорово, но, как показывает практика, NT4/W2000 с NTFS при меньшей производительности обеспечивает еще и меньшую надежность при возникновении бэд блоков, например в MFT. И спрашивается, нах нужны все эти прибамбасы в зоопарке (home/server). А ext2/ext3 нормально выживает после этих "форсмажоров", даже в случае глючной памяти и сбое в файловой системе (реальная ситуация).

sco-killer
()

Ирси, а если потоки так удобны для оболочек, почему же у виндов оболочка хуже, чем тот же kde? Как обычно бред несете.

anonymous
()

Вдогонку ...
Как в NTFS установить права файла "только добавление".
В линуксе это chattr +a filename. Зачем это нужно? Для log-файлов.

sco-killer
()

2Irsi

Почему нельзя рассматривать каталог с файлами в нем как аналог вашего "многопоточного файла"? Тогда можно сказать, что вот в линуксе и пермишены на каждый поток в файле и сами потоки могут быть неограниченного уровня вложенности - типа NTFS отдыхает.

Кстати чем эти "files lite" отличаются от обычных? И чем вся схема отличается от IStorage IStream (не ручаюсь за точность названий интерфейсов) в OLE?

ИМХО, только недоверие MS к собственным файловым системам толкает их постоянно на решения "файловая система в файле".

anonymous
()

Irsi>я тебе не тестовая лаборатория...

Я точно сформулировал вопросы - ничего тестить не требуется. Я не прошу ДОКАЗАТЬ что одна система надежнее другой на столько-то процентов при таких условиях...

Хочется только от тебя узнать про элементарные ситуации, когда можно воочию наблюдать те замечательные свойства NTFS, познать которые ты нас тут призываешь. Ну хоть что-нибудь. Повторяю, случаи когда лажается NTFS в нескольких совершенно жизненных и воспроизводимых за 5-10 минут ситуациях многие видели своими глазами, тогда как, допустим, ext3 выдерживает их совершенно спокойно.

Irsi>Твой вопрос про rawfs в ntfs меня порадовал... Твой уровень осведомленности в FS неплохо демонстрирует (где-то немного больше абсолютного нуля...)

Пожалуйста, продемострируй твой уровень осведомленности в конкретном вопросе: как в WinNT достичь тех свойств FS, которые достигаются (при необходимости) использованием rawfs и tmpfs - какие пропертя надо выставить, регистри поправить или там ещё чего. Или же докупить чего-то надо? Или же это вообще не так делается: задача решается индивидуально для приложения через вызов им какой-нибудь системной функции, изменяющей для него алгоритм кеширования запросов... Ну так как?

Irsi>Для начала рекомендую почитать классиков и понять откуда появилось понятие FS, как оно соотносится с понятием DB, какие тенденции в развитии FS наблюдается, попутно почитать про CODASIL..

Пилять, не надо лекций - дай примеры. И не про появление ПОНЯТИЯ "Файловая система", а про достоинства NTFS или про недостатки, то с чем ты ее там сравниваешь!

Кстати, а твоя "многопоточность"-то укладывается в понятие FS как некой определенной физической и логической структыры данных, или она таки появляется на другом уровне абстракции? Что там у классиков?

speer
()

2sco-killer: ну а если в ext2 что-нибуть критичное для жизни FS пригрохать бед-блоком, то как оно пойдет? :) Вообще уже имхо никем не оспаривается что ext2 менее надежна чем NTFS, хотя бы по причине отсутствия журнала... Я что-то не припомню на NTFS такой беды как потеренные кластеры например... И чекдиска после жесткой перезагрузки - тоже...
Сравнивать производительность систем, работающих под разными ОС и обладающие очень разными возможностями мягко говоря некорректно имхо...
В догонку - посмотри там есть такой атрибут Create Folders/Append Data...;)

2anonymous (*) (2003-02-06 21:01:31.342): рассказы о KDE, "которая лучше чем винды", не смотря на откровенное передирание и сваливание в кучу без всякой системы, всего того что подсмотрели на виндах и маках, мне просто смешны... KDE при худшей юзалибити жркт ресурсов поболее чем ХР... И не надо меня убеждать в обратном...
Кстати, оболочка виндов увы пока почти не использует возможности многопоточности из-за требований совместимости с полудохлой веткой 9х/Ме...:( Ну ничего - этой ветке год жить осталось, потом и Ме станет end of support и тогда-то начнется веселье...:)

Irsi
()

2anonymous (*) (2003-02-06 21:10:18.754): потому что на открытия многопоточного файла требуется на порядок меньше ресурсов чем например для открития дюжины обычных файлов, посещенных в один каталог... Почему? Ну посмотри общий алгоритм, по которому любая ОС открывает файл и объяснений не потребуется...:)

2speer: ПИЛЯТЬ!!!! RTFM БЛЯ, БЕ-ГОМ! Ну твои вопросы... ну я не знаю как даже сказать, с чем сранить... НУ БЛИН!!! Чтобы правильно поставить вопрос, надо знать большую часть ответа. (с) Шекли. Блин, ну пойми ты - твои вопросы на уровне "покажи мне приэмущества ракеты перед стрелой при стрельбе по солнцу"...:(

Irsi
()

Исчо разик - я не спрашиваю, зачем нужна многопоточность, я спрашива. КТО и КАК ЕЁ ИСПОЛЬЗУЕТ. То есть твой ответ пока таков: ACLы в WinNT реализована через механизм многопоточности метаданных файла в NTFS. Так? Другие примеры есть? И желательно чтобы не только метаданные - к их сама систма только и использует - а чтоб приложениям было полезно?

speer
()

2speer: различные адрибуты, предназначенные для расширенного поиска файлов, типа по автору и т.д.
Для хранения ресурсов GUI увы пока не используется по причине требований совместимости с FAT...

Irsi
()
Ответ на: комментарий от anonymous

2anonymous:
>Почему нельзя рассматривать каталог с файлами в нем как аналог вашего "многопоточного файла"?
Год назад я уже спрашивал его об этом...
Даже не пытайся - не ответит:)))

Led ★★★☆☆
()

speer, остань от него. Он только и может что попугаить пару произведений желтой прессы. Заучил треды-хорошо, отсутствие тредов плохо. Объяснить толком, чем хуже отдельные файлы, естественно не может.

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

Гамно эти треды, честно говорю.

anonymous
()
Ответ на: комментарий от Irsi

2Irsi:
>потому что на открытия многопоточного файла требуется на порядок
>меньше ресурсов чем например для открития дюжины обычных файлов,
>посещенных в один каталог...
Меньше на вот столько "___" или на вот столько "_________"?:))
сам придумал или замерял?:)

Led ★★★☆☆
()
Ответ на: комментарий от anonymous

2anonymous:
>возникает при программировании копирования с некой обработкой.
Ага, а ещё все архиваторы придётся переписывать... с учётом
всевозможных реализаций этих тредов...

Led ★★★☆☆
()

2Led: блин, ну пара шевелений извилинами... система получила open (filename) ЧТО ОНА ДЕЛАЕТ ДАЛЬШЕ? Самой общий алгоритм, из нескольких пунктов в студию!

Irsi
()

Ирси, ну ты туп, в натуре. Понятно, что если нужны треды то либо обработку файлов меняешь, либо работаешь с каталогом. Но в случае с каталогом мучаются только те, кому это надо. Все остальные нормально работают.

А работа с каталогом все равно много кому приходится, тем же архиватарам. Каталог+файл намного лучше и удобнее, чем каталог+файл+треды. Ежу же понятно, и только Ирси в недоумках сидит.

anonymous
()

2Led: да ну? zip нормально жмет многотредовые файлы... и этого имхо достаточно...:)
Кстати еще раньше я обяснял как отображать многотредовый файл для устаревших систем, которые про эти треды не заумеют... ;)

Irsi
()
Ответ на: комментарий от Irsi

2irsi
>ну а если в ext2 что-нибуть критичное для жизни FS пригрохать бед-блоком, то как оно пойдет? :)
В ext2 есть копия (и не одна) superblock, если Вы это имели ввиду.
>Я что-то не припомню на NTFS такой беды как потеренные кластеры например... И чекдиска после жесткой перезагрузки - тоже...
Да какой виндовс Вам про это скажет? Может, 95 или 98, но они NTFS не поддерживают :-) И бэд блоков в MFT не было? Повезло, значит. А у меня была ситуация: принесли винт с NTFS5, родной системой не распознается вообще, нет, грит у вас файловой системы, а под линуксом все прекрасно смонтировалось и было отдано по SMB.
>В догонку - посмотри там есть такой атрибут Create Folders/Append Data...;)
Посмотрел, действительно есть, в НТ4 не было, старею :-), а можно пример установки этих аттрибутов, желательно скриптом, если не трудно, конечно.

sco-killer
()
Ответ на: комментарий от Irsi

2Irsi:
>система получила open (filename) ЧТО ОНА ДЕЛАЕТ ДАЛЬШЕ?
Ты говоришь о конкретной реализации? или как бы я это реализовал?:)
Встречный вопрос: система получила open_thread (filename, thread)
ЧТО ОНА ДЕЛАЕТ ДАЛЬШЕ?

Led ★★★☆☆
()

Экономии на тредах, кстати, нет, и быть не может. Потому что большинству эти треды не нужны, а время на их обслуживание уходит. Поэтому ntfs сосет у нормальных fs.

anonymous
()

anonymous (*) (2003-02-06 21:47:28.258): понятно, какова обобщеная последовательность действий при отрытии файла в любой ОС, ты описать не можешь... rtfm прежде чем влезать в спор - оно полезно...:)
Еще раз - обработка файлов меняется только для тех прог, которые знают про существоание тредов. Те которые не знают - работают с потоком 0 как и раньше работали с однотредовым файлом...


Irsi
()
Ответ на: комментарий от Irsi

2Irsi:
>Кстати еще раньше я обяснял как отображать многотредовый файл для
>устаревших систем, которые про эти треды не заумеют... ;)
Кстати еще раньше я обяснял как отображать однотредовые файлы для
"суперновых многотредовых ОС" (напоминаю: VFS)

Led ★★★☆☆
()

2Led: нет я гоаорю о самом общем алгоритме, который используется везде и всегда...:)
Такого вызова нет - открывается файл, а уж после открытия файла идет обращения к треду. Если тред не указан, то считается что обращаются к треду 0.

Irsi
()

"zip нормально жмет многотредовые файлы..."

но он же не сам научился? кто-то же гемороился лишний раз.

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

anonymous
()
Ответ на: комментарий от Irsi

Irsi:
Мы уже с тобой об этом спорили, повторимся для публики?:)
ок, как назначить РАЗНЫЕ права доступа для каждого трэда?
знаю-знаю, сейчас скажешь, что это ТЕБЕ не нужно:)
а файлам в каталоге и многотредовой ФС (реализованной через VFS -
запросто)

Led ★★★☆☆
()
Ответ на: комментарий от Irsi

> 2anonymous (*) (2003-02-06 21:10:18.754): потому что на открытия многопоточного файла требуется на порядок меньше ресурсов чем например для открития дюжины обычных файлов, посещенных в один каталог...

Вот как раз яркий пример недоверия к к собственным файловым системам.

1. Одна из основных операций ФС оказалась слишком дорогой, чтобы её использовать. Очень мило. Отличная ФС ;)

2. Улучшать? Переписывать? Менять дизайн? Не нужно! Надо надстроить еще один уровень (сам по себе ресурсов конечно же не жрущий и сложности в в систему не добавляющий) и заявить что это новая супер-фича предоставляющая невиданные (никем) удобства. А "незначительные" замедление работы и увеличение потребляемых ресурсов нужны именно для этой фичи.

> Почему? Ну посмотри общий алгоритм, по которому любая ОС открывает файл и объяснений не потребуется...:)

"Любая" это NTFS или FAT? ;) Я вас как раз и спрашивал, почему эти ваши файлы-лайт окажутся дешевле обычных и по какому алгоритму NTFS будет открывать ИХ.

anonymous
()

2Led

Извиняюсь, что стормозил с вопросами к Irsi (то то у меня закрадывалось ощущение дежавю).

В каком месяце (приблизительно) это все перетиралось и какая тема?

Напомни, если нетрудно - почитаю архив.

anonymous
()

Как вообще можно сравнивать такую ФС, как ext3 с таким говном, как ntfs? Это нонсенс какой-то просто...

anonymous
()

Вопрос для общего развития: NTFS умеет хранить журнал на другом
винте/разделе?

Вообще, какое это все отношение имеет к клону виндов, который хз
как работает через wine?

jackill ★★★★★
()
Ответ на: комментарий от anonymous

Для начала - спасибо, Irsi, за стойкие попытки объяснить некоторым присутствующим азбучные истины. Даже если я не всегда согласен с формой - содержания у Вас не отнять:) Можно я Вам немного помогу разгребать этот завал (в меру образования)?

1. open - это действительно дорого. И это не свойство физической организации файловой системы. Это свойство уровня vfs в ОС (почти любой ОС - я не знаю ни одной, где бы это было сильно дешево). Пока от имени файла доберешься до конкретных дисковых блоков - "много воды утечет". Конечно, удачная физическая организация файловой системы делает этот процесс дешевле. Но если просто вместо 3 open делать 1 - можно ОЧЕНЬ сильно выиграть. Это и дает жисть многопоточным системам.

3. Алгоритм открытия - в основном, живет в vfs - и только на самом нижнем уровне упирается в "детали" ntfs/fat/ext2. И сам алгоритм таков, что сильно дешевым его не сделать. Ни при каком физическом раскладе. Поэтому, повторяю, идея сэкономить на лишних open - совсем не глупая. Не говоря уже про косвенную помощь в деле целостности данных (если копируешь файл, не забудешь и его иконку:). Кстати, и на маках, если я помню, файлы всегда (?) были многопоточными. Хотя это и десктопная ОС. И оказалось для них весьма удобно...

svu ★★★★★
()
Ответ на: комментарий от svu

2svu

> open - это действительно дорого.

Почему? Где там узкое место? Только дайте, пожалуйста, конкретный ответ, не уподобляйтесь сами знаете кому.

> И это не свойство физической организации файловой системы. Это свойство уровня vfs в ОС

Странно зачем тогда структура file_operations? Я полагал (не большой я спец в fs), что vfs - это большей частью врапперы.

> Но если просто вместо 3 open делать 1 - можно ОЧЕНЬ сильно выиграть.

1. Ключевое слово _можно_. Сколько вы на это поставите? ;) Кроме того тут не 3 open vs 1 open, а 3 open vs 1 open + ЧЕЗ, причем ЧЕЗ не отключается, нужен он вам или нет. (Ити все-таки отключается?)

2.Кроме того можно не делать 3 вызова open, а один вызов opendir и три вызова readdir - и вы получите inode (что с ними делать - не представляю). :)

> Поэтому, повторяю, идея сэкономить на лишних open - совсем не глупая.

Если затраты на поддержу потоков не съедят экономию на open.

Про иконку - это вы так пошутили? Или действительно есть приложения для нормальной работы которых желательная такого рода фс?

P.S. Крайне благодарен за просвещение, но раз эта тема уже обсуждалась, не могли бы _вы_ тогда мне подсказать когда? К сожалению поиск по сайту не работает. Может и бреда буду поменьше нести и уже перетертые вопросы не буду поднимать.

anonymous
()
Ответ на: комментарий от green

2green:
"Если твоя rootfs смонтирована в RO (или неумеет special files) - примонтируй /dev как tmpfs, всего-то делов ;) "

Понятно, что всё объходится. Но дизайн должен быть простым и допускать простые решения. По крайней мере _мне_ больше нравится, когда всё просто (а кому не нравится ? ;)

yakuza
()
Ответ на: комментарий от asaw

2asaw:

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

А вопрос был изначально поставлен так: в NT ACL - атрибут любого объекта. Ну и при чём тут то, что в Linux есть ФС с ACL ? Вопрос про полезность ACL - тоже пустой разговор, если он не нужен, просто откатывайся на старую модель безопасности из 9 бит.

В конце концов, чего было огород городить, если мы наконец сошлись во мнении, что "суть Linux - юниксовая" ?! Я это изначально и имел в виду. А раз так, имеем противопоставление между Linux-ом, "по сути юниксовым" и NT - использующим новый дизайн ОС. Откуда вышли, туда и пришли.

2green: дай пять. за конструктивность ;)

yakuza
()
Ответ на: комментарий от Irsi

Учитывая что VmWare предоставляет езще и хорошо знакомое железо и тп, так что с драйверами не нужно заморачиваться, сравнение все равно некорректно. А исходников дарвина, кстати сказаьт, что-то я не видал. URL?

green ★★★★★
()
Ответ на: комментарий от Irsi

Все ясно. То что ты называешь словом поток, на самом деле чаще всего называют Extended Attribute. Кстати в Linux kernel 2.5 такая штука появилась/начинает появляться.

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

green ★★★★★
()
Ответ на: комментарий от yakuza

Да, я тоже за простые решения. Поэтому я просто храню все права для доступа к разным об'ектам в файловой системе и они всегда у меня под рукой. Где ты предлагаешь пранить права на доступ и другие свойства об'ектов, как они будет переживать рестарт системы (и сохраняться), почему это твое решение проще чем то что уже есть?

green ★★★★★
()

А вот у меня вопрос (быть может такой же глупый как и я):
Какого хрена 10гиговый раздел с НТФС5 видится в дискдряке как почти 10гиговый раздел нтфс + маленький раздельчик на 200 метров без фс???
Что бы это значило??? С тех пор как я удалил нтфс и вернул туда фат32 раздел обратно стал 10гиговым.

anonymous
()
Ответ на: комментарий от anonymous

nazarov_serg303
Точно так.
При компоновке ядра поставишь поддержку нужных тебе устройств и
режимов...
Потом откомпилишь и т.д....
Поставишь вариант загрузки через lilo.Если не понравиться то будешь
грузится по другому варианту меню Лило.
Школьник справиться....
Всё довольно просто...

ranckont
()

nazarov_serg303
Кстати а чё за ошибка ORA-00607.
Копаться не охота.

ranckont
()
Ответ на: комментарий от Irsi


"2341здунам: мне насрать на то как ко мне относятся красноглазые. ;)"

Ну расскажи, расскажи как тебе относятся собратья видовозы ?
Хоть тебе на них и насрать, но будет интересно узнать :)

anonymous
()
Ответ на: комментарий от Irsi


"система получила open (filename) ЧТО ОНА ДЕЛАЕТ ДАЛЬШЕ? Самой общий алгоритм, из нескольких пунктов в студию!"

произойдет установление соединения посредством посылки сообщения
администратору ресурсов и будет вызвана функция io_open() администратора
ресурсов. Хватит ? :)

anonymous
()
Ответ на: комментарий от anonymous

2anonymous:
>В каком месяце (приблизительно) это все перетиралось и какая тема?
1-1,5 года назад... сорри, но точнее не вспомню :(
...и теиу тоже не помню... но точно не про файловые системы :))

Led ★★★☆☆
()

Очень мне понравилось читать про NTFS с "потоками" vs ext3 с каталогоми.
ИМХО, хотя первое явно более прогрессивно, но вот насколько это здорово?
И насколько это быстрее и удобней в реальной жизни, имело ли смысл всё усложнять? Так никто и не ответил.

Аналогии с "железом" наводят на отрицательный ответ. Часто, очень часто, хитрость и извращенность конструкции идёт явно во вред, практичеси не улучшая других качеств.

Всё это похоже на любителей оптимизировать-компилировать кернел. Да, после оптимизации под архитектуру типа -march=athlon размер может уменьшиться на 3-5%. О, как это круто, выиграть 10-15 КБ, в лучшем случае, при 128-256 оперативки. А с учетом времени работы ядра по отношению к другим процессам? Гулькин х... , а не выигрышь.

Может всё-таки каталоги? .... :)
Или.. даешь революцию!

PitStop
()
Ответ на: комментарий от PitStop

2PitStop:
>Может всё-таки каталоги? .... :)
Для приложений, использующих "потоки" - библиотека, которая реализует
их поверх обычной ФС. ИМХО - вполне достаточно и никому мешать не будет

Led ★★★☆☆
()

# А вот у меня вопрос (быть может такой же глупый как и я):
# Какого хрена 10гиговый раздел с НТФС5 видится в дискдряке
# как почти 10гиговый раздел нтфс + маленький раздельчик
# на 200 метров без фс???

Это резерв для преобразования нового тома в динамический.
Почему на Linux все читают man's, а на Win многие не хотят
прочитать даже FAQ (не говоря даже о TechNet)?

WM
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.