XFree 4.4 вышел

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

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

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

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

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

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

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

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

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

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

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

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

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

да ниче, ниче... все нормально :))

>Извини 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 пытаюсь поднять, они утверждают что мое железо и софт который я юзаю у них работает - посмотрим :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2svu: а в чистом, идеализированном виде, ничего никогда не существует...:)

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

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

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

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

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

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

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

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

шаман007 - ну что ??

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

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

2svu: Ну список литературы наверно стоит искать здесь - http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html :)

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

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

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

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

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

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 например...

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

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

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

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

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

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

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

Irsi, вы тормоз, сколько раз вам надо повторить:

CЕТЕВАЯ МОДЕЛЬ ЯВЛЯЕТСЯ ИЕРАРХИЧЕСКОЙ!

Это сильно. А точно не наоборот? Кажется, я тоже на этом месте тормоз...

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

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

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

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

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

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

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

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

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

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

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

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

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