LINUX.ORG.RU

XFree 4.4 вышел


0

0

Изменений гора - среди них
- поддержка 17 платформ
- новая лицензия
- поддержка большего количества железа
- ускорен драйвер nv
- поддержка IPv6
- улучшено автоопределение мышей
- улучшено отображение шрифтов
- Freetype 2.1.4

...

>>> Подробности

★★★★★

Проверено: gr_buza
Ответ на: комментарий от Irsi

а еще ирси агитировал древних инков за использование колесной техники, только его не послушали, и где теперь эти инки?

anonymous
()

Поставил я вчера себе 4.4.0 - сегодня снес :)
Всетаки смена людей сказалась, изменений куча - багов еще больше.
Собралась только с 3-го раза (пришлось хачить - добавлять всякие командочки типа cpp0 и еще чтото).

Фонты постродали (качество рендеринга).

Скорасть работы приятно порадовала (особенно ОпенГЛ на моей Ati Rage128). Ну и вообще так полегче стали (даже места на винте меньше занимают в сравнении с 4.3.0).

Код почистили довольно неплохо - заглядывал в внутр (я в 4.3.0 пару моментов глючных правил, в этих их нету).

Почему отказался - пару раз упали по непонятным причинам, GDM поднять не удалось, качество рендаринга шрифтов. Подозреваю что есл GDM + QT + KDE перрекомпилить с этими иксами то все починится но времени нету может на выходных займусь (или дома).

Мои субъективные выводы: с точки зрения реализации кода - сдвиги положительные и весьма ощутимы, подвело только что это всего первый релиз новой команды так что я буду ждать баг фикс релизов и посвободе поковыряю этот. Разнагласия это конечно минус и большой. А вообще я бы с удовольствием викинул бы XFree86 - больно страшная весч, но реальной замены нету.

zaz ★★★★
()

Да сорри что не втему месагу запостил, а то както аж самому не удобно вы тут про микро-макро ядра, файловые системы и микроскопы и тут я со своими иксами :)

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

Дорогой Irsi, мне порядком задолбало вам объяснять, что вам следует сперва выучиться!
Никогда не следует называть микроядром то, что им не является!
Во-первых вы вводите в заблуждение знающих людей, в следствие чего с вами спорят.
Во-вторых вы смущаете несведующей народ, подумайте сколько людей могут поверить вам:
Если уж так хотите как то определить свой "модульный монолит"(да-да я намеренно говорю монолит) можете назвать его irsikernel, и всем будет ясно, что эта фигня не даст: ни масштабируемости и надёжности микроядра, ни скорости монолита!
Организуйте свою религию/школу/кружок построения систем по принципу "модульного монолита", только никогда не говорите, что это микроядро!

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

Извини zaz, у меня ночью X тоже собирался, я его ещё не поставил, но глюков при сборке не было, gcc у меня 3.3.3 с ключами оптимизации, не знаю ставить или нет, у меня freetype 2.1.7 собран и fontconfig 2.2.90, а этот X опять свои припёр :)

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

а что, обработка исключений уже отменена как класс? где в данном случае "надежность" микрокернела? что-то я не усмотрел. линукс на этой машинке не пробовал, поэтому не скану врать что он все проглотил и не поперхнулся, но.... за каким козе баян, если не работает как надо? для галочки? про БД. я не DBA и тем более не разработчик [R]DBMS, поэтому не могу здраво рассуждать о том на какой прослойке круче базы держать. но что-то подсказывает мне что максимум что нужно БД - целостность файлов. и при прочих равных предпочтение будет отдаваться более быстрой ФС.
теперь про ЕА. IPTC тебе о чем-нибудь говорит? http://www.iptc.org/pages/index.php
http://www.adobe.com/tips/phs8metadata/main.html
это появилось давно и раньше жило в ресурсах на маке (на РС не знаю где, наверное в теле файла. не очень интересовался). сейчас они переезжают на xml. а теперь скажи мне, ничего не напрягает в случае когда документ xml и мета-ресурсы в xml, но живут в потоке? нет ли какого излишества? )))

ты еще о кое-каких своих аргументах забыл. я напомню: plain text хранить в основном потоке, а форматирование в дополнительном. будешь его использовать или сам дошел до понимания маразматичности идеи? )

HellAngel ★★
()

Гонево все это, начали за здравие (XFree 4.4 вышел), а кончили за упокой (микрокернел, etc).

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

>Извини zaz, у меня ночью X тоже собирался, я его ещё не поставил, но
> глюков при сборке не было, gcc у меня 3.3.3 с ключами оптимизации, не
> знаю ставить или нет, у меня freetype 2.1.7 собран и fontconfig 2.2.90,
>а этот X опять свои припёр :)

Я ведь не спорю, если софт проблемна компилится на всех поставках то его врядли бы релизели :), просто моя сильно отличается от всех остальных но с 4.3.0 проблем небыло.
Насчет того что XFree за собой кучу либ таскает меня это тоже убивает !!!
4.3.0 даже со своей libz был (пока хедеры и либу не снес куча глюков была с компиляцией прог узающих zlib). В 4.4.0 вроде сехали на системную - это радует (хотя могу и ошибаться).
Сейчас XServer пытаюсь поднять, они утверждают что мое железо и софт который я юзаю у них работает - посмотрим :)

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

> 4.3.0 даже со своей libz был (пока хедеры и либу не снес куча глюков была с
> компиляцией прог узающих zlib). В 4.4.0 вроде сехали на системную - это радует
> (хотя могу и ошибаться).
Если верить каталогу extras, опять с собой притащили.

> Сейчас XServer пытаюсь поднять, они утверждают что мое железо и софт который я
> юзаю у них работает - посмотрим :)
Тоже хотелось бы, но у меня родственники, особо не поэксперементируешь, даже X новый ставить страшно :)

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

2HellAngel: на счет БД - как ты думаешь с какого бодуна наиболее навороченные БД живут на RAW Partition? :)

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

На счет "переезжают на xml" - что там они на xml переводят поинтересоваться не пробовал? Поинтересуйся, ключевое слово - FrameMaker...:)

На счет раздельного хранения текста и его оформления - ты знаешь это ОЧЕНЬ правильная идея, то что ты не способен осознать удобства такого подхода, это твои проблемы...:)

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

2anonymous (*) (02.03.2004 19:40:31): и где я ввел знающих людей в заблуждение? чем я их ввел? тем что не упомянул про message parsing? ну извини - ты определись, либо они знающие и тогда про это им говорить необязательно, либо они незнающие...:)

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

Irsi, вы хоть понимаете, что описали "модульный монолит" или irsikernel, а не микроядро!
Микроядро - это когда выносят части операционной системы на пользовательский уровень!
Вы совершенно не понимаете термин "микроядро", прошу вас воздерживаться от дальнейшего его использования, поскольку вы не можете агитировать за то, чего не понимаете!

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

2anonymous (*) (03.03.2004 10:58:27):
"Микроядро - это когда выносят части операционной системы на пользовательский уровень!" - это мягко говоря неправда и бред. С таким же успехом можно сказать что RISK это только аккамуляторная архитектура (такми были первые риски, современные - все с набором регистров общего назначения)

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

Irsi, я не утверждал, что в современных микроядрах всё выносят на пользовательский уровень(есть аппаратные ограничения, например архитектура x86) а ядро занимается только передачей сообщений, но сама идеалогия микроядра противоречит внесению сервисов извне в пространство ядра, это правда и не бред!

если под RISK'ом имеется ввиду RISC, то во-первых я не знаю что вы имеете ввиду под "аккамуляторная архитектура", может имелась ввиду стэковая организация локальной памяти?
Идеалогия RISC опять же в другом(кто бы сомневался, что вы и здесь ошибётесь), принцип заключается в создании некоторого набора небольших простых инструкций, в результате чего они способны выполняться быстрее, стороний эффект, в них остаётся место для данных, что разгружает память, в том числе и локальную.
А то что регистры становяться регистрами общего назначения, это вообще-то, так сказать, сторонний эффект, из RISC и вытекает :)

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

То есть, целью RISC не является организация, хм, "какой-либо" архитектуры локальной памяти, а произведения действий в регистрах локальной памяти, то есть главными является загрузка данных в регистры, произведения действий с ними, и их последующая выгрузка(сохранение).

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

Уважаемый Irsi. Вы очень заинтриговали меня своим определением микроядра. Если определение от анонимуса более-менее понятно, в своем роде "классично" - то Ваше определение как-то достаточно размыто (еще немного - и линуховые модули дадут нам право называть линух микроядерным:). Где бы можно было почитать про микроядро в том смысле ("современном":), в котором Вы употребляете этот термин?

Да, про макос. Насколько я читал (тут пробегала неплохая статья про ее внутренности), оная ОС не является "честно" микроядерной. Если уж ссылаетесь на нее, упоминая про микроядра - выдавайте полную инфу, ок?

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

Ага, если учесть что кол-во комманд в современых RISC, превышает кол-во комманд в "классических" CISC архитектурах, то как тут быть с определеним "Что такое RISC"? Скажите еще что там все команды выполняются за один такт, было и такое определение, которое в век суперскалярных архитектур тоже потреряло смысл...:)
Когла я говорил про аккамуляторную архитектуру, то я имел ввиду именно ее, кстати х86 начиналась именно как аккамуляторная архитектура. :) Кстати концепция блока регистров общего назначения появилась лет на ...цать раньше, чем концепция RISC, классический пример такой архитектуры - PDP-11 :)
Вынесение всего, чего только можно на пользовательский уровень, а на уровне ядра - только минимум, это идеал, который как известно не достижим, в реальной жизни это экстремизм. :)

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

Из этих рассуждений можно сделать вывод - сегодня RISC как таковой не существует - это просто зонтик, под который любят прятать процессоры их изготовители (точнее, их маркетологи). Самое сильное утверждение, которое можно сказать - процессор НЕ является RISC, если позволяет выполнять операции над операндами в памяти. Все остальное при желании может рассматриваться как RISC.

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

А я вот собрал Xfree 4.4.0 ... проинсталил .. собралось без ошибок с первого раза ....

далее .... startx не работает .. сделал symlink с Xfree86 на X и все заработало ...

какие-то не понятнные проблеммы с xkb ... ругается что правил нету ... пока не копался по чему ...

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

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

2Irsi: как же, вот водка например -- только что лично проверил - существует.

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

Irsi, поймите же наконец, микроядерность, это именно вынесение всего что только можно на уровень пользователя, на уровне ядра остаётся то, что по каким-то причинам(обычно аппаратным) вынести не удаётся, если есть возможность выполнять часть ОС на уровне пользователя, то это так и делают, это и есть "религия" микроядра!
Идеал - когда микроядро занимается только коммуникациями между процессами!

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

2anonymous (*) (03.03.2004 14:10:17): поймите дорогой онанимус, меня НЕ интересует никакая религия, в том числе - и какая-то "религия микроядра". Меня интересуют вполне практические вещи, и практика говорит, что такой экстремисткий подход, а именно - вынесение всего что только можно на пользовательский уровень, к микроядрам никакого отношения не имеет. Если не верите - почитайте что об этом умные люди пишут, их список можно взять здесь - http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/people-former.html :)

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

Да, сколько раз вам повторять, экстремизм и религия тут не причём, такова архитектура микроядра, не нравиться делайте свою, но никогда не говорите что это микроядро.
Тут основной принцип не называть микроядром то, что им не являеться.
Ваш пример, всего лишь пример модульного монолита, не имеющего к микроядру никакого отношения вообще!

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

Вы дали список людей. Но, все-таки, не могли бы вы ТОЧНО привести ВАШЕ (или одного из этих умных людей) определение микроядра. Или наиболее сильное утверждение по поводу того, что является (или не является) микроядром. Спасибо.

Кстати, насколько мне известно, все-таки QNX укладывается в классическую модель микроядра. То же про OSF/1, которая, вроде, честно лежала на микроядре Mach. Если я не ошибаюсь - значит, классическое микроядро существует в чистом виде, и не в одном (в отличие от RISC, про который, вроде, мы договорились, что его нет как такового).

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

про БД: все правильно, ты уловил тенденции, но не понял причин :) они стремятся жить в RAW именно потому что для хранения таблиц, логов и сегментов НЕ НУЖНА СЛОЖНАЯ ФС. а теперь напряги еще немного то, что у тебя выполняет функции мозга и подумай о следующем: есть несколько разных БД (я о навороченных), у каждой из них есть несколько типов метаданных, да и сами данные (тут мое имхо, но опровергни попробуй) могут быть организованы несколькими разными способами (в зависимости от приоритетов количество_данных / скорость_поиска_добавления_удаления_индексации / надежность / что_либо_еще. теперь вопрос: не кажется тебе что сложность ФС, которая будет удовлетворять всем требованиям разработчиков xDBMS будет расти по экспоненте? а если еще одним разработчиком больше? а еще одной реализацией еще одного алгоритма поиска? а если не только реляционные базы будем расматривать? а если....?

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

про метаданные: вычислительные ресурсы стоят дешево и продолжают дешеветь. тебя же не напрягает то, что вин для простого показа содержимого директории (cmd.exe не рассматриваю) выполняет миллионы команд как CPU, так и GPU? типов файлов множество и оно увеличивается. хранение метаданный в ФС похоже на утопию - либо слишком развесистое множество параметров, либо очень небольшое подмножество (например дата модификации и владелец). и то и другое имхо неудовлетворительно. команду file используешь? что помешает ее модифицировать для извлечения метаданных из xml-based типов файлов?

про раздельное хранение форматирования и содержимого: преобразование formated_text->plain_text является примитивной задачей для программы в которой будет создан текст с форматированием. но после правки ветви с plain text в программе, не поддерживающей форматирование как будет происходить синхронизация? не смеши :)) а уж если пользователь умеет пользоваться diff/patch - он поймет в каком редакторе текст открыть или какой текст нужно сохранить чтобы его дальнейшая обработка была не обременительна

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

Вы уходите от ответа. Я просил определение или наиболее сильное утверждение.

За список - спасибо, посмотрю.

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

2HellAngel: ну начнем с БД... Как по-твоему что делают навороченные БД с RAW партицией? Чтоб разобраться с этим вопросом надо вернуться ненмного назад, где-то в 60е годы и понять что на самом деле DB & FS это одно и тоже, это искуственное разделение одного понятия, а именно "структурированное хранилице данных" и разделено оно было по причине очень ограниченных вычеслительных ресурсов (у крутейшей System/360 например было 16Mb RAM Max.). Фактически когда мы говорим о современых БД, мы говорим только об одной из трех моделей БД, а именно о реляционной модели. FS является почти классическим представителем другой модели - ирархической, хотя имеет и элементы сетевой модели (links). Но не надо забывать что есть и еще одна модель, для которой и реляционная и ирархическая модель являются всего лишь подмножествами. Это сетевая модель, и насколько я понимаю позже ее незначительные модификации стали называть модным словом объектная. Так вот - потоки это всего лишь один из элементов замены классических FS на нормальное хранилище данных. FS должна, просто обязана содержать все необходимые примитивы для обеспечения эффективной реализации как ирархической, так и реляционной, так и сетевой модели БД.
Так что возвращаясь к вопросу "Челают навороченные БД с RAW партицией?" ответ имхо очевиден - создают на ней некоторое структурированное хранилице данных, которое вполне можно назвать специализированной, или даже продвинутой FS. :) если не верищь - посмотри как организована AS/400 - среди прочих приколов там есть DB2 в роли FS...:)

Твои аргументы в пользу xml напоминаеют мне аргуметы сторонников МИР'а, когда я им доказывал необходимость наличая древовидной структуры каталагов, "Зачем это громоздить это в систему, когда с этим вполне справляется прикладная программа? Томсон полный козел что так сделал, поэтому юникс никто не использует и никогда не будет использовать". Смешно, да? А прошло всего-то 15 лет...

Про форматирование - а синхронизация не нужна, не веришь, проверь...:) Просто не надо зацикливаться на том что любой тег состоит из закрывающего и открывающего...:) По крайней мере в BeOS я редактировал текст в его редакторе, "раскрашивал", сохранял, открывал в vi, провил... и форматирование сохранялось...:) Господи, в конце-концов я без проблем его мог прочитать в vi, то же самое, но даже отформатированое в xml/html, без специальной програмки читается очень тяжело... а если возмем rtf например...

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

про принципиальные отличия RISC тоже прогнал. и насчет аккумуляторной архитектуры. у процессора RISC I их было 78, а в RISC II - 138 (в регистровом файле). в машине IBM PC RT, которая базировалась на проекте 801 у процессора было 16 регистров. интересно, ты хоть изредка сверяешься с фактами или пишешь только отсебятину? :))

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

Irsi, не выпендревывайтесь, опять вы не фига не знаете!
Сперва были файловые БД,
потом иерархические(деревья и сети),
потом реляционные!
Так что двойка вам по истории БД!

Вроде как есть объектные(сам их я не видел), есть реляционно-объектные и постреляционные(это объектно-иерархические).

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

не поверишь - если я открою в vim'e форматированный текст (html например или rtf) и поправлю его, форматирование тоже сохранится. только это несколько неудобно, ты прав. ты мне расскажи как выполнить синхронизацию и внести изменения в форматированный текст из неформатированного. только в максимально формализуемом виде плз. :))

а по поводу того что ФС это БД, а значит пусть у нас ФС будет выполнять функции БД - не надо. вот есть у нас несколько моделей представления данных и описания связей между ними - так пусть и несколько систем хранения будет. для древовидной - ФС в том виде, к которому привыкли, для реляционной - (... назови как угодно, только не ФС). пусть даже это живет на чистом разделе и создается командой mkfs.relationDS ;)) пока еще объектные БД так и не вышли из зачаточного состояния и я сомневаюсь что они способны подменить отработанную десятилетиями подсистему хранения данных (ФС).

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

2anonymous (*) (03.03.2004 17:40:07): таак, вообще сам термин БД появился в 60е, и тогдашней литературе действительно понятия DB & FS как бы это сказать... смешивались.
А дальше, начало 70х, это CODASIL, и там уже во всю обсуждаются все эти три модели, сам CODASIL это типичная сетевая модель.
Так что пшел в жопу, сам RTFM бегом! :)

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

2HellAngel: ты еще дальше копни по RISC и убедишся что само определение этого понятия ОЧЕНЬ размытое. :) Не надо мне рассказывать про практические реализации, я в курсе что все они были с регистровым файлом. :)
Ну и какаяж из FS "отработана десятилетиями"? Кроме UFS & HFS я что-то ничего не припомню, чтоб лет 20 просуществовало... Ди о от самой ирархической модели воют, пытаются ее в сетевую преобразовать постоянно. :)

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

2svu: забей, дрочун красноглазый не понимает разницы между графом и деревом. Да, дерево это конечно подмножество графа, но это не есть одно и тоже. Сетевая модель это граф, ирархическая - дерево. Это грубо говоря.

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

Хм, смотря как рассматривать дерево :)
Если дерево это сеть, несодержащая циклы, то, наверно, наоборот :)

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

Irsi - сами вы дрочун красноглазый!
Сказано очень грубо, надо говорить - "Сетевая модель расширяет древесную" (C) Леприкон, дискретка

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

ты еще FAT забыл :)
а десятилетиями отработаны не конкретные системы, а сама концепция. и если отдельные личности пытаются расширить ее за счет включения части возможностей с сопредельных классов, то это означает не то что идея плоха, а то что она отработана "до дыр". нет чтобы вместо солянки переключиться на те же БД нереляционные, пытаются к самолету плуг приделать

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

2HellAngel: идея многопоточности и ее подмножеств и разновидностей (EA, resource fork и т.д.) тоже неплохо отработана и активно применяется в течении приблизительно 20ти лет. :) То что этого нет в линуксе - проблема линукса. Хотя почему нет - есть, только упертые использовать не хотят...

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

только ты сказав "а" говори и "б" - они применялась с разной степенью активности, а сейчас от нее отказались те кто применял :))

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

если уж совсем точным быть - Apple отказалась. а EA похерено вместе с OS/2
у меня кстати есть кое-какие мысли, но не знаю насколько они дельные. насколько идея хранения acl (любых, 3х3 тоже, а также owner:group) вместе с файлом хороша? если иерархия пользователей хранится в LDAP|AD, то нет ли смысла хранить и права (точнее отношения между объектом и субъектом) в LDAP|AD? конечно, для простых случаев - явный оверхед, но для развесисой клюквы - почему бы и нет? нет у кого почитать что умного пишут (меня теоретическая часть больше интересует) об этом всем (разграничения полномочий)?

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

Что пишут умного - не знаю:). А вот что я могу сказать из "общих соображений".

LDAP задумывался как хранилище с относительно быстрым доступом поиска и относительно медленным доступом модификации. Поэтому дерганье его при каждом создании-изменении(chmod/chown)-удалении файла должно приводить к немалым тормозам всей системы. А вот списки пользователей-групп - вещь весьма и весьма статичная, поэтому класть их в LDAP - самое "оно".

Впрочем, это все лишь общие мысли...

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

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

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

меня в меньшей степени интересует конкретная реализация механизма хранения. более примитивное объяснение (на самом деле я толком еще и сам не знаю и поэтому не могу сформулировать чего хочу) сводится к следующему: есть система управления правами unix-like, есть win-like, novell-like и т.д. это относится не только к acl или 3х3 правам. а общие закономерности в построении систем управления доступом, хранении ресурсов и учетных записей есть интересно? где-то давно читал о таблицах, по одной оси которых - объекты ОС (файлы, директории и пр.), а по другой субъекты (люди, группы и т.д.), а на пересечении - разрешения. Вот что-нибудь о подобных вещах узнать было бы интересно

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

2HellAngel: и с какого бодуна ты решил что Apple отказалась от HFS?! Да ни разу! Десятка так же активно юзает data fork/resource fork как и классика...:) В ntfs сейчас потоки применяются все более активно, поскольку сдерживающий фактор в виде ветки 9х (и требования обратной совместимостей с оной) уходит в прошлое... Что еще? Потоки поддерживаются в QFS и никто от них отказываться не собирается... Что там еще - OS/400? Ну там вообще более продвинутая система чем многопоточная FS...:) Классические юниксы? Кое-кто из них поддерживает потоки, да и вообще они как-то помирают потихоньку увы... И не стоит забывать что они уж под очень специфические и узкие вещи заточены... В том же линухе начали появляться FS с поддержкой потоков, так что поверь - лет через 5 все красноглазые будут приводить это как преимущество линуха...:)

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