Apple: BSD в 3 раза популярнее Linux на десктопе

Для EasyRider. Мне кажется, что сейчас последние отщипенцы верстают в Прыщмэйкере. Ну зачем в нем верстать? Когда есть Quark и Indesign? Да и говорить об этом в таком месте не прилично, Linux не ховатало еще и верстальщиков - для этого существует масса альтернатив. Если мы наченем Linux пихать в задницу еще и верстку, то как раз и выйдет что типа Виндовз, оставте хоть эго не винным.

2 последний анонимус. Вы не начнете. Вы пока только ведете пустой треп о чистоте пингвинской расы.

Читал, долго смеялся...:) Ребятки, а вы хоть раз в жизни мак видели? :) Имхо - нет, имхо даже не удосужились сходить на их сайт и почитать...

2Avel: ну ты вообще имхо гонишь... что там яблочники зажали? То что они взяли из *BSD, то они и вернули в виде открытого кода. Это для начала. Да и вообще - ты представляещь себе разницу между микроядерной ОС и ОС с монолитным (ну ладно - модульным) ядром? Так что по-хорошему имхо они не только юридически (это понятно), но и в этическо-моральном плане не были обязаны открывать исходники дарвина.

2 Irsi: Парень, Дарвин открыт. А мак они тут в натуре не видели, как и Mach, BSD и NeXTstep... И вообще ни хера не знают.

2anonymous (*) (2002-02-19 18:56:38.0): ну а я о чем? Ядро MacOS X (aka Darwin) - OpenSource, распостраняется под APSL (Apple Public Source License)... И вообще - насколько я понимаю (точно не уверен - не успел досконально изучить данный вопрос) некоторые фичи из дарвина появятся во фряхе пятой... бекпорт...

>Ребятки, а вы хоть раз в жизни мак видели?
Ну и где я что сказал не то?

2AC: да нет - с тобой-то я вообщем согласен в данном вопросе... Одно мелкое замечание - сравнивать gimp & photoshop друг с другом это все равно что сравнивать между собой vi & QuarkXpress...:)
И еще - про красноглазового все же я придумал :) И там это имело вполне конкретное обозначение, просто оно очень быстро стало нарицательным :)

>И еще - про красноглазового все же я придумал :)
В следующий раз при употреблении этого слова поставлю твой копирайт:) Не собираешься подарить это слово в безвозмездное пользование широкой прогрессивной общественности?:)

2AC: да уже подарил похоже :) Копирайт не обязателен...:)
P.S. Смотрю мое определение линуксоида прижилось... Это радует...:)))

Нечего там портировать. Darwin - это _не_ бсд. Смотри пост выше (сорок какой-то по номеру). Блин, кто-нибудь из присутствующих смотрел в сорцы Дарвина?? Слышали звон, да не знают где он.

2anonymous (*) (2002-02-19 21:08:32.0): эээ,давай определимся что есть *BSD? Четкое определение в студию, плз! А вот после этого будем говорить на тему "BSD-не BSD"...
И к слову - с исходниками какого из BSD ты предлагаещь сравнивать исходники Darwin? :)

2 Irsi <<сравнивать gimp & photoshop друг с другом это все равно что <<сравнивать между собой vi & QuarkXpress...:)

Cравнивать между собой vi & QuarkXpress незачем т.к. они созданы для решения разных задач. Также и gimp с Photoshop. Gimp не предназначен для prepress целей в отличии от Photoshop.. Если сравнивать gimp - то мне кажется:, с ImageReady

2EasyRider: ну это ты не мне объясняй, а красноглазым, которые утверждают что gimp для полиграфических целей подходит...:)
А вообщем согласен... Хотя имхо отсутствие в нем возможности работать с цветовой моделью, отличной от RGB, делает его полностью непригодным для работы... Почему? Ну например заниматься ретушью и вообще чисткой изображений зачастую гораздо удобней в CMYK или Lab... Просто зачастую помеха, грязь и т.д., которые в RGB присутствуют на всех трех составляющих, в CMYK или Lab сосредотачиваются только на одной что разумеется очень сильно облегчает процесс ее удаления...

Мне вот интересно... Уже на протяжении долгого времени говорят об отсутствии ЦМИКа в гимпе... Мoжет кто-нить тогда абыснит, почему это так? Неужели настолько трудно реализовать? :) Или это опять legal issues?

Потому что сам по себе CMYK не имеет особого значения - все цветовые системы координат приводятся друг к другу хорошо известными способами - наука есть такая - "колориметрия". Так что преобразовать (теоретически) можно и совсем необязательно, что это должен делать gimp.

Практическая же ценность возникает только в том случае, если обеспечивается сквозная калибровка всего тракта цветопередачи - от (слайд-)сканера через монитор и до фотоавтомата. А для этого нужно ЗНАТЬ цветовые характеристики большого числа оборудования, которыми производители вовсе не горят желанием делиться (или как Apple - выпускать своё).

Во-вторых эта задача УЖЕ решена на других платформах вполне эффективным по критерию цена/качество образом - так нужно ли это повторять под Линуксом?! Зачем? Для "победы на десктопе" - так этот позыв только в зараженных маркетоидной горячкой анонимусовских головах и существует...

Хотя, "времена - они меняются", поэтому может кто и делает такое, но решения эти уж точно будут не Free и не Open, по крайней мере в ближайшем будушем.

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

Cyan Magenta Yelow blaсK Color Scheme не запатентована и не залицензировна и матрица преобразований из RGB тоже, потому как это просто математика... А вот цветовый параметры и кривые цветокоррекции красок, люминофоров, ccd-матриц и т.п. отнюдь не всегда известны и достпны.

2speer: без обид пожалуйста, но у тебя в голове каша... CMYK нужен не только для цветоделения и цветокалибровки. См. мой постинг выше например, а также почитай что говорят об увелечении контрастности например в теме про новый гимп...
А на счет цветоделения и цветокалибровки - на это есть стандартный цветовой профиль устройства (файл с расширением .icc), который обычно идет с любой более-менее приличной железкой. Так что "ЗНАТЬ цветовые характеристики большого числа оборудования" это не проблема. :) За описанием формата профиля и прочей инфой надо прогуляться на сайт с оригинальным названием - www.color.org ;)

>>>без обид пожалуйста, но у тебя в голове каша

Какие уж тут обиды - я вовсе не обсуждал откуда и из каких нужд взялся CMYK и это его артефактное применение, придуманное практикующими ретушерами-мышевозилами (вместо использования подходящих алгоритмов)!

А тебе, чтобы не смешить народ важно-пустомельной аргументацией, советую всё же посмотреть учебник по колориметрии, из которого узнаешь, что преобразование RGB --> CMYK (и во все остальные системы цветовых координат) происходит однозначно и без потерь, а вот в обратную строну - увы, нет! Поэтому RGB был, есть и будет _основным_ форматом цветокодирования.

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

А что касается твоей ссылки про ICC - ну так там же и можно проичитать про всякие Limitation и трудности обеспечения правильной _сквозной_ цветопередачи, которые ничуть не отменяют моих объяснений. Повторю еще раз:

В gimp нет поддержи кодирования цвета в формате CMYK по нескольким причинам:

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

2. Как бы там на практике не извращались с CMYK полиграфисты, оптимально цветоделение делать из RGB прямо в те координаты, которые отражают процесс конкретного печатного станка - четырехцветные машины ведь давно низший класс полиграфии.

3. Добавление поддержки CMYK в gimp ничего принципиально не изменит в улучшение его применимости для целей полиграфии - одного gimp'a явно мало для полного решения этой задачи.

4. Unix/Linux - система взаимодействия инструментов и кубиков, полиграфическая графика - комплекс весьма ощутимых физических объектов и противоречивых взаимодействий между ними, по сравнению с этим особенности ОС и ее утилиток - малозаметная и ничего не решающая деталь. Если Линукс начнут таки пользовать в заментных для корпоративной Америке масштабах - ну так и будет там цветное DTP, перетащат заинтересованные лица. Нет - ну так и нет.

Или если кто попытается отгрызть кусок рынка у владеющих им сейчас и будет экономить на ОС, впрочем Apple сама так решила поступать. В факе про Дарвин написано, что открытая ОС - дешевле для поддержки и развития. А за полиграфию они зубами держаться изначально. Когда появился первый Mac - кубик с монохромным дисплеем, все остальные настольные компьютеры уже имели цветные видеосистемы (и Apple II тоже!). На недоуменные вопросы эппловцы отвечали, что отныни их принцип - все что видно на экране должно быть напечатано в том же виде и на бумаге, и с этой дороге они не свернули.

2speer:
"тебе, чтобы не смешить народ важно-пустомельной аргументацией, советую всё же посмотреть учебник по колориметрии, из которого узнаешь, что преобразование RGB --> CMYK (и во все остальные системы цветовых координат) происходит однозначно и без потерь, а вот в обратную строну - увы, нет! Поэтому RGB был, есть и будет _основным_ форматом цветокодирования."

Угу... "Стандартный" CMYK позволяет иметь 2^32 оттенков, "стандартный" RGB всего 2^24 (для тех кто в танке - 4й байт в так называем 32х разрядном RGB на самом деле не несет никокой информации о цвете, обычно это альфа-канал) Именно поэтому RGB->CMYK проходит без потерь, а обратно - с потерями...:) Вообщем это ты смешишь народ, я боюсь что с сидящим радом полиграфистом ща истерика от твоей фразы случится... Ничего кроме "ну идиот" он сквозь смех сказать не может... :)

"Причина этого - трехкомпонентная физиология цветового зрения у человека."

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

А теперь по пунктам
1. Полный бред, RGB очень далека от модели человеческого зрения. CMYK впрочем тоже... Далее - RGB & CMYK одинакого естейственны (или неестейственны еслихочешь) Просто первая лучше подходит для излучающих устройств отображения, вторая - для тех изображений что мы рассматриваем в отраженном свете (читай про основные и доп. цвета короче). К слову 99% объектов мы видим именно в отраженном свете...

2. Ну этот бред даже комментировать не буду... я уже показал что "стандартный" RGB хранит меньше инфы о цвете чем "стандартный" CMYK...

3. CMYK и другие цветовые модели нужны не только для полиграфии. Их наличае помогает обрабатывать отсканированные изображения, изображения захваченные с TV/VCR/DVD/Digital Photo и т.д. Точнее только в RGB качественно обработать эти изображения, просто убрать шуми, повысить кое-где резкость и т.д - речь вовсе не идет о предпечатной подготовке, очень трудно, практически невозможно...

4. Еще раз - поддержка CMYK и других моделий нужна не только и не столько для полиграфии. Если я тебе начну перечислять все что нужно для полиграфии, то ты очень быстро поймешь что в первую очередь нужен универсальный GDI и следовательно для начала надо отказаться от иксов... Ну или кардинально их переделать, введя в них понятие GDI...

И напоследок - ну про Apple мне рассказывать не надо, ок? :) Боюсь я лучше тебя знаю маки их историю... а также что и по каким причинам они делали...:)

Еще раз повторю - ты пустозвон! Хочешь трендеть за-ради шума, чтобы побольше о деталях поменьше о сути - изволь, только за#;%(?лся ты уже изрядно. Я ведь все-таки отвечал на вопрос, почему cmyk нет в gimp, а ты зачем-то рассказываешь про процессы, про разрядность форматов, смех в зале и т.п. - спасибо не надо, мне тоже есть где pre-print, сам print, и post-print наблюдать вживую и с кем посмеятся. Или ты считаешь, что если в gimp засунуть cmyk - то линукс превратится в платформу для предпечатной подготовки, ясноглазый ты наш?!

Ну а теперь немного конкретики, хотя куча которую ты навалил - почти вся мимо темы, несмотря на натуральность фрагментов (плохо с мыслеварением?):

>>>Стандартный" CMYK позволяет иметь 2^32 оттенков, "стандартный" RGB всего 2^24

Следи за базаром - я описывал особенности RGB и CMYK исключительно как принципиальных способов цветокодирования, поэтому не важно сколько разрядов и почему отведены в уродливых "стандартных форматах" - ты бы видеокарты в пример привел которые еще 10 лет назад с 4 метрами были супер-профессиональными - и ничего, все готовилось-печаталось.

>>>Именно поэтому RGB->CMYK проходит без потерь, а обратно - с потерями

Нет не только поэтому, главная причина - в математической неоднозначности обратного преобразования независимо от разрядности, учебники ты все же почитай.

>>>Хе-хе... Вперед за Нобелевкой, если ты разумеется сможешь это доказать... и т.д.

Два абзаца сплошной пены, из которой видно, что ты (прикалывась ради флейма?!) делаешь вид, будто не знаешь что

1. Цвет - он только в голове цвет, причем в головах разного типа - разный, цвета же как природного (объективного, физического и т.п.) объекта или характеристики НЕ СУЩЕСТВУЕТ.

2. Цветовое зрение у приматов возникает благодаря наличию в сетчатке глаза трех рецепторов с разными пиками спектральной чувствительности. Поэтому и все цветоопеределение-цветоописание ЧЕЛОВЕЧЕСКОГО (а не кошачьего, к примеру) восприятия так или иначе отталкивается от трехкоординатного представления.

3. "Убогая линейная RGB (и все остальные color shemes) вовсе не только для описания МОДЕЛИ цветового зрения нужна (хотя и без нее там не обойтись) а для КОДИРОВАНИЯ, ИЗМЕРЕНИЯ и ВОСПРОИЗВЕДЕНИЯ визуальных характеристик объектов, причем главным образом с целью СИНТЕЗА (создания видимости ;))) этой самой цветности. Причем цвет здесь надо понимать в отрыве от яркостной составляющей - это отдельная тема.

4.Для синтеза цвета - то есть для ответа на вопрос сколько и каких компонентов известных цветов надо смешать, чтобы результат воспринимался другим желаемым цветом - RGB-описание как раз и дает однозначный ответ, CMYK - нет. Но зато с CMYK можно лучше описать особенности этого смешивания в печатном процессе, разумеется не сам по себе а с добавлением всяких графиков, кривых, таблиц для разного оборудования, красок, бумаг, лаков и т.д.

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

>>>И напоследок - ну про Apple мне рассказывать не надо, ок? :) Боюсь я лучше тебя знаю маки их историю... а также что и по каким причинам они делали...:)

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

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

:))))))))))))))))))))))))))))))))))))))))))))))))))))))

Irsi>>>Если я тебе начну перечислять все что нужно для полиграфии, то ты очень быстро поймешь что в первую очередь нужен универсальный GDI и следовательно для начала надо отказаться от иксов.

!!!!LOL!!!!

Тебе бумажным ролем по голове не попадало?!! Лучше сразу признайся, чтобы время больше не тратить. Если же нет, попробуй прояснить несколько моментов:

1. "Универсальный GDI" - это что, когда на canvas все кидается, предварительно задав ее параметры, да-а-а?! Такая универсальность, когда на много-много "канв"-"канвов"-"кaнвей" рисовать приходится - одна для экрана, другая для принтера, еще несколько - для пленок и т.д. Или на одну растеризовать, а потом ее бедную туда-сюда преобразовывать с немерянными потерями... Ты это имеешь в виду, или я не въезжаю, чего-то пропустил?

2. Что такое, по-твоему, ентот GDI, кроме как API для растеризации с заданными параметрами и в выделенную область памяти, а?!

3. Ну и чем это концептуальное угребище (GDI) лучше-универсальнее-правильнее чем отрисовка из Postscript?!!!

4. Где в _полиграфии_ начинается и где кончается использование твоего сраного GDI - и в RIPaх оно где-е-е-е? А ведь "в первую очередь нужно" и именно для полиграфии - сам сказал!

5. X-Window system (aka protokol) чем GDI-то работать мешает? Зачем его выкидывать - он сути ничего кроме как доступа к области для вывода и проброски туда-сюда событий мышки-клавиатуры (хошь локально, хошь по сети) ничем больше и не занимается...

6. Не ты ли не так давно объяснял про ужасы отсутствия в Линухе "многопоточной файловой системы" - теперь еще GDI потребовалось?

Ну, а так продолжай в том же духе. Очень смешно получается, когда привыкаешь к твоему чувству юмора.

2speer: так ну все ясно...
Для начала - чтоб модель могла максимально возможное число цветов она обязана учитывать особенности функционирования "распозновающего устройства", в данном случае - человеческого глаза. Это вообще Lab-модель, которая к слову считается наиболее точной из всех имеющихся. Да кстати, твое утверждение "Цветовое зрение у приматов возникает благодаря наличию в сетчатке глаза трех рецепторов с разными пиками спектральной чувствительности." не соответствует действительности, извини...:) Это не так...
Продолжаем - да CMYK-модель является "аппаратно-зависимой", то есть чтоб цвет полученный при выводе на конкретное устройства был правильный надо иметь так называемый "цветовой профиль устройства". Но тоже самое относится и к RGB - или ты серьезно думаешь что краски, бумага и т.д. бывают разные, а люминофор на всех мониторах светится одинакого? :) Но про использовании цветовых профилей я даже и не заикался - вот тут-то и пойдут лицензионный проблемы вообщем-то...
Кстати, в какой модели по-твоему работают самы популярные нынче струйные принтеры? Правильно - в CMYK в подовляющим своем большинстве... трехцветки и шестицветки - вообщем-то экзотика...
Да, кстати - а ты ничего не читал про так называюмую "электронную бумагу"? Технология грозится в перспективе вытеснить не только ЭЛТ, но и ЖКИ... Тоже CMYK к слову...:) Правда она еще очень молода и говорить о ее скором и обязательном пришествии преждевременно...:) Но "вкусностей" в ней очень много, например возможность спокойно свернуть такой экран в трубочку...:) Ну это так, к слову пришлось...:)
Да на счет "неоднозначности преобразования" - можешь ее продемонстрировать с формулами в руках? :)

Ну а теперь про GDI... Ты видимо неверно понял что я под этим понимаю... Это НЕ Windows GDI! точнее Windows GDI это всего лишь один из примеров (не самый удачный если честно) реализации идеи "абстрактного графического устройства". То есть мы просто выводим свою графику на некое абстрактоное графическое устройство, а уж чем оно конкретно акажется - принтером, дисплеем, Х-терминалом или еще чем-либо не наша забота, а забота системы...
К слову на основе PS тоже делался GDI, например в NextStep, более того PS это тоже почти GDI, а если брать в расчет еще и DPS (Display PostScript), то и вообще совсем себе GDI... Маки - еще один из вариантов...
Я не говорю что в иксах такое сделать нельзя. Можно наверное... Только это будет уже нечто сильно отличающееся от современных иксов :) Хотя с другой стороны вариантов много может быть, согласен...
Про многопоточные FS рассказывал именно я... Да мне их нехватает, яб сказал смертельно не хватает ибо все то что в многопоточных FS делается легко и просто, с минимальным затратом сил и процессорных ресурсов, в однопоточных FS требует плясок с бубнами и все равно в результате тормозное и малостабильно дерьмо выходит...

Продолжаем упорствовать в невежестве, получается еще раз LOL:

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

Ладно, это не так - ты пролистнул три графика спектральной чувствительности этих самых "колбачков и палочкав" в книжке, ну так как же тогда все происходит?

Как объясняется хотя-бы с мычанием и на пальцах необходимость и достаточность для синтеза цвета именно трех красок и почему неглупую кошку хоть на короткое время, но заинтересует ЧЕРНО-БЕЛАЯ фотография соплеменника (как и отражение в зеркале), а вот самое натуральное ЦВЕТНОЕ изображение ту же кошку оставляет совершенно равнодушной?! Банальную глупость, что у кошки черно-белое зрение, сразу рекомендую отбросить - во-первых это не так, а во-вторых, картинка в оттенках серого имеется и на цветной фотографии...

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

Я именно это и ответил первом посте, объясняя челу, почему просто поддержки cmyk недостаточно - чего спорить-то было?! И именно про проблемы с доступом к лицензированой или просто закрытой инфе шла речь.

>>>Кстати, в какой модели по-твоему работают самы популярные нынче струйные принтеры?

Во-первых, это не относится к вопросу и теме разгоревшегося флейма, во -вторых это неважно, так как они напечатают тебе картинку и из программы, которая ничего не знает ни про CMYK вообще, ни про "поддерживаемую модель" в частности - все пересчеты (из RGB!) драйвер сделает, что в Виндах, что в Маке, что в Линуксе (см. драйвера струйников Epson, Lexmark и т.д.), потому как именно в драйвер вбиты все эти цветовые координаты, учет нелинейностей и свойств бумаги, оптимизация с учетом характера изображения и текучести красок и фиг знает что-еще, из-за чего процесс цветной печати по сложности и неоднозначности можно сравнить только с изготовлением музыкальных инструментов на конвеере.

РЕДАКТИРОВАНИЕ граф.файлов в CMYK на самом деле ДЕЙСТВИТЕЛЬНО нужно именно в профессиональном пре-принте, когда надо что-то подправить ближе к концу процесса и нет возможности или нежелательно возвращаться к оригинальным форматам. Мы о полиграфии говорим или о домашней распечатке фоток и оформлении web-страничек?!

>>>Да, кстати - а ты ничего не читал про так называюмую "электронную бумагу"?

Разумеется читал, но причем здесь CMYK, RGB, Gimp и процессы вытеснения и замещения технологий?! Чем дальше, тем больше в сторону и пятками назад...

>>>Да на счет "неоднозначности преобразования" - можешь ее продемонстрировать с формулами в руках? :)

Не-е-е, это надо ехать в гараж, откапывать снег, отмораживать замок, ломом открывать дверь, а потом перерывать кучу барахла в поисках коробки со старыми книгами... Но качественно это легко себе представить:

100%С + 100%M + 100%Y = 100%White; 0%С + 0%M + 0%Y = 100%Black (теоретически) или же 100%White (практически)?!! А куда девать те проценты black, которые имеются в составляющей K?! Ну и начинается - калибровка уровня черного-белого, нормализация цветовых составляющих и т.д. Разумеется, для практике обходы неодназначности сформулированы в виде набора правил, но математическую строгость это убивает напрочь.

>>Это НЕ Windows GDI! точнее Windows GDI это всего лишь один из примеров (не самый удачный если честно) реализации идеи "абстрактного графического устройства".

Именно так - сделать конкретную реализацию "абстрактного GDI" для вывода экран Xы мешают ничуть не больше чем Win32,MacOS или NexrStep APIs - так чего-же именно от них надо "ДЛЯ НАЧАЛА отказаться"?!

>>>Про многопоточные FS рассказывал именно я... Да мне их нехватает, яб сказал смертельно не хватает ибо все то что в многопоточных FS делается легко и просто, с минимальным затратом сил и процессорных ресурсов, в однопоточных FS требует плясок с бубнами и все равно в результате тормозное и малостабильно дерьмо выходит...

Ну-ну, расскажи-ка что происходит c многопоточностью, когда файл открывается не на локальной системе, а по сети?! Как там с "затратами ресурсов", "тормозами" и "стабильностю" выходит. Впрочем в контексте программирования слово "стабильности" звучит точно также как "вторая свежесть" в отношении осетрины... Дальше можно не обсуждать - потому как нет базового понимания "природы вещей" и это не лечится ни дипломами об образовании ни стажем работы.

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

2speer: ну прекрати тормозить и прочитай что я сказал выше, для чего КРОМЕ препринта нужны разные цветовые модели в графредакторе... Еще раз - даже если фотка предназначена для публикации на вебе зачастую в процессе ее обработки приходится использовать модель, отличную от RGB, тот же CMYK... Просто это удобней и позволяет получить лучшие конечные результаты быстрей.
Просто наличае в программе всех основных цветовых моделей (RGB, CMYK, Lab) недостаточно для того чтоб говорить об препрессе и строго говоря имеет к препресу отношение постолько-поскольку.
Да, на счет человеческого глаза - как известно палочки, которых чтоль раза в три если не ошибаюсь, больше чем колбочек всех видов, не имеет никакого отношения к цвету. Более того - по все длине спектра глаз имеет разную чуствительность... Посему говорить о линейной модели, в которой нет отдельного параметра для хранения яркости и в придачу которая не учитывает неравномерность чуствительности глаза как о самой лучшей мягко говоря имхо глупо...
Да, кстати ты не прав, "100%С + 100%M + 100%Y = 100%White; 0%С + 0%M + 0%Y = 100%Black" это неверно...:) Правильно 100%С + 100%M + 100%Y = 100%Black; 0%С + 0%M + 0%Y = 100%White, в теории разумеется, при идеальных красках :)))) RTFM на тему основных и дополнительных цветов! :)))

Теперь по поводу GDI... А ты подумай почему я говорю что фактически иксы непригодны для реализации на их основе GDI... Попрбуй хоть немного попытаться проработать идею создание GDI на основе иксов и ты придешь к необходимости очень кардинальных изменениях в протоколе, настолько кардинальных что фактически это означает отказ от иксов :)

На счет многопоточных FS - когда файл на такой FS открывается по сети все нормально получается... Если обе системы умеют работать с такими FS, то затраты ресурсов существенно меньше чем реализация аналогичной функциональности на однопоточных FS, если одна из систем не знает, то незначительно выше...

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

>>>ну прекрати тормозить и прочитай что я сказал выше, для чего КРОМЕ препринта нужны разные цветовые модели в графредакторе.

Ну так попробуй все-же признать существенность того, что я тебе принципиально на это возразил. Или так и останешься на уровне навыков мышевозилы-ретушера.

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

Первое предложение - банальное и бессодержательное. Второе, которе ты сложноподчинил первому - еще большая банальность, весьма коряво свормулированная. Посему выводы получаются уж совсем ни к чему не годными:

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

Исчо разик - RGB вовсе не модель цветного зрения, а способ КОЛИЧЕСТВЕННОГО определения цвета, с помощью которой можно решить задачу синтеза цвета для восприятия его человеком. Заказчик тыкает пальцем в альбом - хочу вот такой цвет, берутся его RGB-координаты, берутся координаты красок и с помощью набора формул или прямо линейкой по диаграммам можно получить пропорции, в которых эти краски надо смешать. Никакая модель зрения, нелинейность, спектральная чувствительнось тут НЕ ПРИ ЧЕМ - это результат обобщения опытных данных, под которые потом уже были подведены теории, физологии, модели, ИИ и много чего еще.

То же самое можно сделать и по CMYK координатам, плюс там можно проще учесть как на восприятие цвета скажется характеристики бумаги и способ печати, НО RGB описание является минимальным и однозначным набором данных, позволяющим ЗАДАТЬ ЦВЕТ. Все. CMYK и RGB - принципиально исходят из одной и той же модели зрения (чисто эмпирической), потому как у них задача одна и метод ее решения тоже одинаков и пересчитывается одно в другое легко (если определиться с условиями калибровки).

А вот причина, почему именно три параметра надо знать для определения цвета - как раз в физиологии того, как ощущение цвета возникает. И там все принципиально просто (а в деталя - очень сложно) - излучение, попавшее на поверхность сетчатки вызывает отклик у ТРЕХ независимых рецепторов, имеющих три РАЗНЫЕ кривые спектральной чувствительности и именно ТРЕХКОМПЕНЕТНЫЙ вектор амплитуды их возбуждения и классифицирестя мозгом как наблюдение того или иного цвета.

Поэтому, чтобы вызвать ощущения ОДНОГО и того же цвета у человека вовсе не обязательно ТОЧНО воспроизвести спектр излучения объекта, а достаточно всего лишь так подобрать три цветовые компоненты, чтобы их результирующее совместное воздействие НА КАЖДЫЙ из рецептеров давало нужную интенсивость всех трех компонентов нервных импульсов.

А у кошки (с двумя типами рецепторов) подобранные для человека соотношения вызывают абсолютно другие ощущения и цветная фотография для нее - неидентифицируемый хаос пятен. Черно-белая же хоть на что-то похожа, так как яркостный анализатор и у человека и у кошки работает сходным образом, только у кошки чувствительность и перегрузочная способность его намного выше. Видел небось, что кошка прикрывает зрачки не когда слишком ярко (даже на солнце она может не щюрится) а когда надо рассмотреть детали - задействует оба рецептора и получает свой вариант цветов, а не только контрастную яркостную картинку, которой пользуется когда надо ловить-убегать-драться.

Нелинейность зрения при это ни CMYK ни RGB не учитывают. По двум причинам - цветовое зрени у человека - очень грубый, неточный и в абсолютном смысле НЕКАЛИБРУЕМЫЙ анализатор (в отличии от т.н. "абсолютного слуха" "абсолютного зрения" как-то не наблюдается) и там допустимы очень большие погрешности. Два - там где эта нелинейность становится заметной - начинаются пограничные области - где все сереет-чернеет (малая яркость) или белеет (большая).

Вот и получается, что по-большому счету задавать надо именно (а) ЦВЕТ и (b) соотношение яркости различных цветов для не очень большой области удобной для восприятия человеком общей освещенности, И RGB для этого более чем достаточно.

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

По поводу GDI.

Так я ж тебе сказал, что, imho, Xы ничем не затрудняют реализацию GDI (а сам этот GDI на рабочем месте препринта для полиграфии вообще не имеет значения - важно GDI в RIP) - поэтому твоя очередь хоть что-то конкретное сказать, чем все-таки Xы мешают работе GDI - на экран-то они выводят так, как позволяют по-максимуму карта и монитор, а обратно с экрана в граф-файл ничего не попадает, какой бы GDI не был, а растеризуется и печатется все с разрешением офсета, которое больше чем у любого экрана на ПОРЯДОК.

>>>На счет многопоточных FS - когда файл на такой FS открывается по сети все нормально получается

Где это так нормально получается - пример (название API), где оно одинаково для локального и сетевого файла?

Второй вопрос - а там, где нет "многопоточности" - чем открытие трех файлов не может заменить открытие одного в трех потоках? Есть и другие варианты - еще более быстрые...

speer: нда... а ты а ты погряз в теории и полностью оторвался от практики. Для чего вообще нужен растровый редактор? Для того чтоб в нем рисовать? Нет! Рисовать гораздо удобней в векторном редакторе, типа иллюстратора или корела... Впрочем я знаю и один (подчеркиваю - один) растровый редактор, орентированный именно на создание изображений, а не на обработку готовых - это Painter... Но сравнивать с ним гимп еще нелепей чем сравнивать гимп с фотошопом...:)
Итак растровый редактор в первую очередь предназначен для обработки готовых изображенийй, полученных сканированием, отснятых цифровым фотоопаратом, захваченные видеокадры и т.д. Совсем не обязательно что результат этой обработки будет выводиться на печать, наоборот - скорей всего в современном мире это будет сохраняться на CD-R для дальнейшего просмотра на мониторе. Так что забуть про препрес, забуть! Для препреса нужно очень много чего, CMYK необходим, но далеко не достаточен! Но самое главное что я тебе пытаюсь втолковать что CMYK (а также Lab и другие модели) НЕОБХОДИМЫ на этапе обработки изображений, даже если НЕ предпологается выводить их на печать. Отсутствие оных альтернатив RGB сразу лишает возможности пользоваться огромным количеством разнообразных приемов что в свою очередь затрудняет, а зачастую и просто делает невозможным, получение пристойного результата обработки. Еще раз - забудь про печать, ну нету принтера, на CD-R храним и печатать не собираемся.
И еще о "самой лучще и правильной" модели - RGB. Ладно в полиграфии используется CMYK потому что среда представления изображений является не излучающей, а отражающей и посему для нее являются "родными" не основные, а дополнительные цвета... Но обоснуй почем форматы JPEG, MPEG* и вообще все что относится к видео не используют для хранения и передачи видеоизображений модель RGB? Вроде для них, где практически все устройства отображения являются излючающими, "родной" являеся именно RGB? :) А когда поймешь почему так, рекомендую посмотреть на компы 30ти и более летней давности, подумать о чем больше тогда думали - об качестве изображения или об экономии ресурсов... Тогда може и поймешь почему в компах такое неоправданое засилие RGB...
Да, на счет GDI - блин, сам попробуй спроектировать его на основе иксов... Энтузиазма быстро поубавится, ей богу...:) Вообщем - да, можно рассматривать Х-сервер как нечто равноценное принтеру...:) Только сам подумай что из такого подхода вытекает :)
На счет многопоточных FS - а я говорил что это идеал? Уж тогда AS/400 ближе к идеалу...:) Нет это просто имхо один из наиболее удачных копромисов, еще один шаг на слияние двух искуственно разделеных понятий - FS & DB...

>>>Но самое главное что я тебе пытаюсь втолковать что CMYK (а также Lab и другие модели) НЕОБХОДИМЫ на этапе обработки изображений, даже если НЕ предполагается выводить их на печать.

Утверждения приводимые без каких-либо доказательств от многократного повторения аргументами не становятся.

>>>И еще о "самой лучще и правильной" модели - RGB.

Да, с логикой у тебя непоправимые проблемы , ньюаносов ты не различаешь - дальтония. Я не говорил, что она вот так-то просто "лучшая и правильная". Я утверждал (с примерами) только что она НЕИЗБЫТОЧНА, ДОСТАТОЧНА и АДЕКВАТНА обслуживаемой задаче.

>>>Среда представления изображений является не излучающей, а отражающей и посему для нее являются "родными" не основные, а дополнительные цвета

Мдяяя, совсем до ламмерства опустился. Парниша, нету дополнительных цветов самих по себе - ДВА цвета могут быть дополнительными друг к другу, а по отдельности они просто цвета. И ничего в их ОПИСАНИИ (координатах) не меняется от того рефлективный или излучающий источник наблюдается.

>>>Да, на счет GDI - блин, сам попробуй спроектировать его на основе иксов... Энтузиазма быстро поубавится, ей богу...:)

Ты ведь пробовал, да ;) Ну так поведай, на чем обломался - я именно от тебя хочу это услышать?!! Либо не пытайся больше с важным видам щелкать кого-то по носу - в ответ получишь ссылку на этот тред. Кстати, а почему xv не испытывает проблем с выводом практически всех известных форматов через Хы на экран, а через PS на принтер?! И почему "абстрактный GDI" их поимеет?!

>>>Вообщем - да, можно рассматривать Х-сервер как нечто равноценное принтеру...:) Только сам подумай что из такого подхода вытекает :)

Что из этого вытекет - во-первых, что так называемое GDI - всего лишь название модели для растеризации графики, реализуемой в виде некоего железного или программного модуля, Х-ы этому слабо мешают, по той же причине, по какой не важен тип интерфейса между компутером и устройством вывода (принтером или еще чем). Ну и наконец отсюда вытекает, что все твои разговоры, о том что Xы надо выкинуть в первую очередь - это bla-bla-bla.

Кстати, а вот когда Маки были монохромными и Ventur'ы Publisher со своим собственным GDI на писюках еще не было и в помине (Виндов тем более не было) - тем не менее компьютеры в полиграфии уже были - страшно громоздкие и дорогие комплексы солидных фирм, так вот - рабочие места там были на Юниксах - а на них, разумеется, X-о подобные штуки попадались.

>>>Но обоснуй почем форматы JPEG, MPEG* и вообще все что относится к видео не используют для хранения и передачи видеоизображений модель RGB?

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

>>>На счет многопоточных FS - а я говорил что это идеал? Уж тогда AS/400 ближе к идеалу...:)

ТЫ НЕОДНОКРАТНО УТВЕРЖДАЛ СЛЕДУЮЩЕЕ: "Отсутствие многопоточной FS в Линуксе - страшная проблема для его эффективного (для пользователя) и удобного (для программиста) применения в десктопных задачах и не только там".

А где же пример, когда такая FS используется для этих задач совершенно недостижимым для линуха образом?! Или AS/400 - десктопная система, или ты - идиот. Или проблемы вовсе не там, где ты их постоянно откапываешь и другим в нос свои гнилые (как оказывается) находки тычешь.

PS. И про BSD Copyright vs. GPLicense у меня тоже фактический материал еще не кончился, так что еще посмеемся когда будет повод.

2speer: я уже приводил пример когда при обработке изображений необходимо сменить цветовую модель. Повторю еще раз - очень часто бывает что при смене цветовой модели помеха, которую желательно удалить сосредотачивается в одном эээ... компоненте (в одном из цветовом канале или в яркостном). Тоже самое - при повышении контрастности. Удобней обрабатывать ОДИН компонент в не-RGB модели. Все это позволяет добиться более качественных результатов и более быстро. Если для тебя возможность получить более качественный результат при меньшей затрате времени и сил для тебя не является аргументом для добавления нескольких сотен строчек кода, то дальше бесполезно что-либо обсуждать имхо. И имхо это доказывает что RGB не является ни адеквотной, ни достаточной для обслуживаемой задачи. Со свой стороны я могу сказать что пока будет такое показательно наплевательское отношения к нуждам юзверей, все OpenSource на десктопах так и останется игрушкой для безденежных маргиналов ибо маргиналы с деньгами покупают маки. :)
Про основные и дополнительные цвета - ты разумеется прав. Но если ты изучал колометрияю, то ты в курсе что RGB называют основным набором цветов или кратко основными цветами, а CMY - дополнительным набором цветов или сокращенно дополнительными цветами. Почему я надеюсь обяснять не надо? :)
Про GUI - блин, для начала придется кардинально переделывать работу с фонтами... Потом насколько я помню - добавлять некоторые графические примитивы, какие точно - не спрашивай, не помню уже... А потом получается из иксов что-то очень похожее на DPS...:))) Ну про то что нужна поддержка ICC-профилей я и не говорю... Вообщем как в том анекдоте где после собки доработать напильником... Почему-то не смотря на всю заманчивость использовать всю мощь иксов, ни одна из контор, которая делала ОС для полиграфии не стала доделывать иксы, а начала писать свой гуй...
На счет mpeg & jpeg - да, уверен. С телевидением я мало дело имел (если не считать рипанье DVD в DivX), а вот на счет полиграфии... Не один год в полиграфии проработал, ток что ты меня не поймаешь :)
На счет FS - а ЭТО я и сейчас продолжаю утверждать! Да, многопоточные FS НЕ ЯВЛЯЮТСЯ ИДЕАЛЬНЫМ РЕШЕНИЕМ. Но это решение УДОБНО, ПРАКТИЧНО, поскольку позволяет решать многие задачи, которые без них решать затруднительно, если не сказать иначе - практически невозможно. Но стргой сторонв многопоточные FS не позволят решить ВСЕХ проблем, например проблему с большими БД, для них все равно будут нужны RAW партишены... Это просто удачный компромис.
А про AS/400 я помянул только потому что там нет FS в том понятии, к которумы мы все привыкли... Это другая крайность, если хочешь - идеал к которому надо стремиться.
Блин, да для тебя наверное древовидная структура каталогов является чем-то привычным, неким обязательным отрибутом FS... А я помню еще времена когда мне также как я сейчас пытаюсь доказать необходимость многопоточных FS, приходилось доказывать необходимость наличия в FS древовидной структуры каталогов... Это я убеждал заменить RSX-11 на Unix...:)

Ну все уже пошло на четвертый круг, поэтому и отвечать нечего - смотри выше.

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

>>>На счет mpeg & jpeg - да, уверен. С телевидением я мало дело имел.

И напрасно так уж сильно уверен - RGB там в основе основ - теоретически и агоритмически вся МОДЕЛЬ ЦВЕТОВОСПРОИЗВЕДЕНИЯ в ТЕЛЕВИДЕНИИ именно на RGB описании и построена. А вот _кодирование_ производится самыми разнообразными способами, в зависимости от задачи. Если пользоваться твоей логикой, то получится например, что в SECAMе тоже RGB нет :))) - цветоразностные сигналы передаются и яркость отдельно (она функционально подобна K в CMYK). Может на этом основании и этот формат в графредакторы засунуть?!

Что касается mpeg/jpeg, то во-первых они могут нести в себе кодировку цвета самыми разными способами (разные фреймы по разному даже!), формат это допускает, а конкретную выбирают исходя из требований размера/потерь/способа декодирования/динамики сюжета и хрен знает чего еще в голову взбредет. Изначально именно за уменьшание объема и простоту декодирования боролись - а на качество плювали.

>>>На счет FS - а ЭТО я и сейчас продолжаю утверждать!

Вот на этом я тебя и словил, если ты до сих пор не понял - на упертом алогизме основных громких и _конкретных_ заявлений, подкрепить которые ты можешь только _общими_ и невразумительными рассуждениями.

Теперь ты пустился в банальные и поэтому неоспоримые разглагольствования что "fs разные важны, fs разные нужны". Это-то все так, как и признание, что AS/400 здесь не в тему. А ведь если кто не знает, об чем речь - обтёк бы и пошел бы как оплеванный размышлять об своем невежестве, вместо того чтобы об тебя ноги вытереть. Но тебе и это как божья роса - ты все равно свое гнуть продолжаешь:

>>>Да, многопоточные FS НЕ ЯВЛЯЮТСЯ ИДЕАЛЬНЫМ РЕШЕНИЕМ. Но это решение УДОБНО, ПРАКТИЧНО, поскольку позволяет решать многие задачи, которые без них решать затруднительно, если не сказать иначе - практически невозможно.

Так я дождусь от тебя "удобного и практиченого" примера, хотя бы _иллюстрирующего_ это неоднократно произнесенное и столько же раз оспоренное утверждение?! Увы, нетути ничего...

>>>Блин, да для тебя наверное древовидная структура каталогов является чем-то привычным, неким обязательным отрибутом FS.

С чего ты это взял, я этого не говорил, да ты и не спрашивал! А насчет удобства BD для этих целей - тоже есть разные мнения. Некоторые весьма авторитено доказывают, что табличные и реляционные модели данных - то еще уродство, а SQL - вообще полное говно, несмотря на математическую проработанность модели. Но обсуждение этого - финт в сторону от темы - а ты всегда слинять пытешься, когда твои радужные пузыри лопаются - я на это не ловлюсь.

Ладно, давай закончим на этом, еще ведь встретимся...

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

- Ты в чем чаще работаешь - в RGB или CMYK?
- Чаще в RGB, иногда в CMYK.
- А преобразовать можно?!
- Да легко.
- А обратно?
- Лучше не надо, там всякое бывает, попал в цмык - ну и сиди там...
- Но отдаешь-то в CMYK?
- Ну, если попросят, а так обычно RGB во-всюда идет... Слушай, не мешай, а?

Такая вот сценка из жизни без претензий...

speer, все проще. Покажи формулы перевода RGB в CMYK и обратно. Заодно расскажешь, чем CMY от CMYK'а отличается... :)

Па-а-а-шел ты, знаешь куда! Я свою задачу выполнил, а формулы - они в справочниках и учебниках, знания - в голове, голова - на плечах, мастрество - не пропьешь. Н наконец - учись, студент!

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

2CybOrc:

Извини, кажется я тебя зря куда-то там посылал - смайлика в конце не заметил. И CMY(K) не сразу с ним соотнес... Так что, с меня пиво!

2speer: на счет цветокодирование в видео - почитай про Lab-модель... К слову в нормальных редакторах она есть... И еще - ее цветовое пространосто больше чем у RGB... Потом продолжим разговор...
Извини, но чтение лекций по БАЗОВЫМ вещам и понятием это вне моей задачи здесь... RTFM! ;)
К слову - не смотря на кажущуюся аналогичность K-компонеты в CMYK и яркостного сигнала в видео, на деле их роль отличается принципиально.

На счет многопоточных FS - мне надоело приводить примеры. Но попробую еще раз.
1. ACL. Все расширенные права на файл удобно хранить в виде отдельного потока. Например это дает возможность разрабытывать свою систему прав, НЕ модифицируя саму FS например. Просто запускаем демона (сервер в терминах микроядерных ОС, где к слову такой подход наиболее эффективен), который создает поток ко всем файлам с нужным ему форматом и начинает следить за соблюдинием прав... Я знаю что в линуксе придется делать еще кое-что и упрощаю намеренно, чтоб не потерять за деревьями лес.
2. Гуй, десктоп. Как известно для современного десктопа файлу нужно иметь несколько больший набор атрибутов, чем то к чему многие привыкли. Это иконка, соответствующая файлу, тип файла (что в нем хранится - графика (и в каком она формате), текст(и в каком он формате) и т.д.), программа-обработчик даннго типа файлов, "метки" и т.д... Ну понятно что тип файла можно обозначать его расширением (убогое решение за которое надо благодорить мелкософт с ее убогим фатом), программу-обработчик можно хранить в некой БД (получается аналог виндовзячего реестра правда), там же можно хранить и иконку для него... Но все это убого, негибко (например тяжело задать конкретному файлу конкретную иконку) и ресурсоемко.
3. БД. Небольшие реляоционные БД, типа постгреса, очень неплохо выигрывают в производительности если каждая их таблица хранится в отдельном потоке. Для больших БД правда все равно нужен RAW-партиция, им многопоточность действительно не подмога, там нужны более сложные решения.
4. Текстовые редакторы. Очень удобно хранить текст в одном потоке, а инфу о его форматировании - в другом. Это дает возможность ВСЕГДА вытащить текс, даже ценой потери оформления. Зачастую выжен именно текст, а оформить всегда можно потом... Если Вы не вытаскивали инфу из файлов экзотических текстовых редакторов, например чирайтера, то Вам не понять...:) Впрочем более современный пример - PDF-file... Помните каких усилий требовало решение вытащить из него хотябы текс еще несколько лет назад?
Второй плюс - файлы конфигов/исходники. Я могу выделить цветом/шрифтом тот участок, на который я считаю обратить внимание в дальнейшем и спокойно продолжит редактирование другой части. При этом, поскольку инфа об оформлении хранится в другом потоке, мне не придется иметь особый компилятор/прогу, которые понимают данный формат или неки предпроцессор, который перед скармливания оных файлов компилеру/проге, выдирал бы из него инфу о форматировании... Прога просто читает тот поток, кде находится чистый текст, про остальные потоки она может даже просто не знать. К слову - я смогу редактировать этот файл например в vi и при этом не терят инфу о форматировании. Более того - если хранить текст в первом (или нулевом - как считать потоки), то не придется переделывать все уже имеющиеся проги (тот же gcc), чтоб они спокойно понимали все эти оформленные файлы...

Хватит примеров? Или продолжить?

К слову на тему SQL... Да, я придерживаюсь что реляционная модель это гавно, но для определенного круга задачь она удобна и оптимальна. Да, это все-го лишь частный случай более общей модели БД. Да, реляционная модель абсолютно не подходит для реализации на основе нее FS и множества других задачь. Почитай про кодасил - в его терминах и реляционная модель БД , и FS, и электронные таблицы и еще черт с бантиком описываются как частные случаи и не более того.

   Угу... "Стандартный" CMYK позволяет иметь 2^32 оттенков, "стандартный"
   RGB  всего  2^24  (для  тех  кто  в танке - 4й байт в так называем 32х
   разрядном  RGB  на  самом  деле  не  несет никокой информации о цвете,
   обычно  это альфа-канал) Именно поэтому RGB->CMYK проходит без потерь,
   а  обратно - с потерями...:) Вообщем это ты смешишь народ, я боюсь что
   с  сидящим  радом полиграфистом ща истерика от твоей фразы случится...
   Ничего кроме "ну идиот" он сквозь смех сказать не может... :)
А тебя, идиота, все-таки из ISP выперли обратно в полиграфию (иначе с чего
это около тебя полиграфисты сидят? или все полиграфисты-идиоты работают в
ISP)? Так и надо. Скоро в школу выпрут, а потом в садик.

   2speer: на счет цветокодирование в видео - почитай про Lab-модель... К
   слову  в  нормальных  редакторах  она  есть...  И  еще  -  ее цветовое
Нет, в видео используется YUV модель. Так как глаз более чувствителен
к яркости чем к цвету U и насыщенности V, на U и V выделяется в 2 раза
меньше бит, чем на яркость - и благодаря этому получают еще большую
степень сжатия. Кодировать видео в CMYK - идиотизм (в нем 4 компоненты, тогда
как для глаза - базисный вектор из 3 составляющих - RGB - то есть не нужно хранить на 33% больше данных).
 Иди, учись, идиот.

   1. ACL. Все расширенные права на файл удобно хранить в виде отдельного
   потока. Например это дает возможность разрабытывать свою систему прав,
   НЕ  модифицируя  саму  FS  например. Просто запускаем демона (сервер в
   терминах   микроядерных   ОС,   где  к  слову  такой  подход  наиболее
   эффективен),  который  создает  поток  ко  всем  файлам  с  нужным ему
   форматом  и  начинает  следить  за  соблюдинием  прав...  Я знаю что в
   линуксе  придется  делать  еще  кое-что  и  упрощаю намеренно, чтоб не
   потерять за деревьями лес.
Сам что-ли это придумал, идиот? Тогда любая прога сможет модифицировать
этот поток с ACL и вся система защиты идет в ..
   3.  БД.  Небольшие  реляоционные  БД,  типа  постгреса,  очень неплохо
   выигрывают  в  производительности  если  каждая  их таблица хранится в
   отдельном  потоке. Для больших БД правда все равно нужен RAW-партиция,
   им  многопоточность  действительно не подмога, там нужны более сложные
   решения.
Конечно ты переписал постгрес для использования потоков, сделал много
разных об[ективных бенчмарков и сделал вывод, что многопоточная FS для
постгресса - предпочтительнее. Пожалуйста приведи ссылки на рез-ты.
 А на самом деле постгресс для каждой таблицы заводит файл. Благодаря
этому отдельные таблицы можно разнести по разным винтам, что ты бы не
мог если бы хранилось в неск. потоках. Использование многопоточности
нисколько не улучшит производительность постгресса в общем случае.
   4.  Текстовые  редакторы. Очень удобно хранить текст в одном потоке, а
   инфу  о  его  форматировании  -  в другом. Это дает возможность ВСЕГДА
   вытащить  текс,  даже  ценой  потери оформления. Зачастую выжен именно
   текст, а оформить всегда можно потом... Если Вы не вытаскивали инфу из
   файлов  экзотических  текстовых редакторов, например чирайтера, то Вам
   не  понять...:) Впрочем более современный пример - PDF-file... Помните
   каких  усилий  требовало  решение  вытащить  из  него  хотябы текс еще
   несколько лет назад?
И сталкиваемся с дичайшим геморроем при попытке записать такой док-т
на CD (iso9660 однопоточна), копированием на дискету (FAT однопоточна),
выкладыванием в инет.. Это просто мечта конкурентов. Другое дело -
док-т хранить как архив с неск. файлами как это делает openoffice.
   Второй плюс - файлы конфигов/исходники. Я могу выделить цветом/шрифтом
   тот  участок,  на  который  я  считаю обратить внимание в дальнейшем и
   спокойно  продолжит  редактирование  другой части. При этом, поскольку
   инфа  об  оформлении  хранится  в другом потоке, мне не придется иметь
   особый  компилятор/прогу,  которые  понимают  данный  формат  или неки
   предпроцессор, который перед скармливания оных файлов компилеру/проге,
   выдирал  бы  из  него инфу о форматировании... Прога просто читает тот
Кажется, ты не писал конфиги и тем более программы лет 10. Для пометки
существуют комментарии, если ты не в курсе. Выделения цветами и шрифтами
будут в лучшем случае понятны только тебе в течении месяца.

Ладно, над таким инвалидом детства, как ты, смеяться грешно..

2Irsi:

Ты так и не понял разницу между "моделью" и "координатами цвета в какой-либо системе цветоопределения" или просто паталогически не способен к более-менее точным формулировкам?! И поэтому сам все время пытаешься поправлять там где УКАЗАНО, что формулировка заведомо употреблена нестрогая? Впрочем, тема уже закрыта.

На счет поточных FS:

Напоминаю (в последний раз, надоело уже!!!): ты утверждал, что Линуксу они необходимы для (bla-bla-bla) и посколько "красноглазые" в силу своего пионерского идиотизма неспособны это понять, а значит и не собираются реализовывать - то достичь это самого (bla-bla-bla) в Линухе не получится, или это будет криво, тормозно и "нестабильно". Я потребовал от тебя доказательства этого утвержедения и для этого попросил привести пример систем, сопоставимых с Линуксом по области применения, где бы эти самые преимущества поточных FS были бы реализованы и задействованы в чем-нибудь из твоего (bla-bla-bla) .

На самом деле, надо было бы просить пример, где эти самые FS сделаны на уровне архитектуры системы, а сама система сравнима с *никсом, ну да ладно.

Ты в ответ опять приводишь общие рассуждения, как оно могло бы быть здорово там для сего и этого и пятого и десятого. НЕ КАТИТ - ЭТО НЕ ПРИМЕР, а только благие пожелания - задач и архитектур нетрудно нафантазировать сикоко угодно! К тому же, например, обработка XML-файла позволяет рассматривать его как многопоточный на любой платформе, где есть средства работы с этим модным форматом, Линукс понятно в их числе. А сам XML очень даже подходит для реализации structured storage файла (это из Win32 API, если они его как-нибудь не заалиасили за то время, что я им не пользовался) - может ты эту штуку имел ввиду, рассуждая о многопоточности?

ИТОГО: мой тебе совет - НИКОГДА больше не приводи эти свои выдумки в качестве примеров, показывающих (как тебе кажется) интеллектуальную ущербность людей, которых ты называешь "линуксоидами" с уничижительными эпитетами. Они в достоинствах/недостатках своих фаворитов без тебя разберутся, не отвелекаясь на бредни. А я тебя постараюсь проконтроллировать.

PS. Могу подкинуть новую темку для выдувания очередной порции пузырей! Слушай: по моим наблюдениям линуксоиды в своей темной массе совершенно не в курсе примуществ вычислительных систем с троичной логикой перед системами с двоичной, а это научный факт! Надо открыть им глаза на их собственное ничтожество, ну и вволю поприкалываться. Берешься?!

Онанимус иди почитай про Lab-модель и расскажи чем она отличается от YUV...:)))) Если ты думаешь что Lab & CMYK похожи, то ты глубоко заблуждаешься идиот. :)
Про ACL в виде потока - так сделано в NTFS например... И хрен ты его модифицируешь "из любого приложения". Как сделано - RTFM.
Я знаю как постгресс хранит свои БД. И к слову для разнесеня таблиц по разным дискам существуют другие методы, более эффективные. :)
Про совместимость с однопоточными FS - нет никаких проблем. Во-первых по-хорошему файлы перед записью на такие носители стоит архивировать, файл с архивом - однопоточен, а внутри него потоки сохраняются... Т.е. это небльшая модернизация форматов tar & gz/bz2. Это во-первых. А во-вторых эта задача давно решена и без архивации, стандартными средствами всех многопоточных ОС - они эмулируют многопотчность на однопоточной FS с помощью кучки файлов... Да, это малоэффективно и сильно снижает производительность, но для дискетки и сидюка это неважно, у них и так скорость невилика и пользуются ими очень редко по сравнинию с HDD...

2speer ты хочешь примеры? Пожалуйста!
NTFS - ACL реализована через потоки, также в потоках хранится некая дополнительная info о файле, насколько я помню используемая для быстрого расширенного поиска...:) Все остальные описаные возможности ПОКА не задействованы, насколько я понимаю их задействование планируется после отказа от поддержке последнего из 9х - WinME. Поддержка 95 & 98 уже прекращена как известно.
Храниение текста отдельно об инфе о его форматирование - программы Simple Text (MacOS), и Notepad (BeOS & QNX 6.x). Кстати именно в BeOS я убедился что разукрашивать файл конфига очень удобно :) Хотя это разумеется не отменяет комментарии - просто удобное дополнение к оным.
Использование потоков для хранения всяких доп. атрибутов файла с целью поддержки гуя - MacOS (лучший гуй всех времен и народов), BeOS (второе место по гую, первое место за связку макоподобный гуй + bash), в QNX 6.x пока не ковырял, но имхо Photon использует.
Заодно почитай про EA в HPHS и как они используются в OS/2... EA - частный случай, урезанаая реализация многопоточности. К слову - HFS/HFS+ ее data fork & resource fork это тоже урезанная реализация многопоточности, "двухпоточность". В BFS & QFS многопоточность истинная... И что-то на эту тему (добавление многопоточности) сейчас происходит с UFS... Что конретно - я еще не разбирался если честно. Может ограничатся вариантом с EA, а может и нет... И что там сделало Apple с UFS в ее Darwin/MacOS X тоже смотреть надо...
Ну а для линукса... RaiserFS - см. что они собираются туда добавить в будующем...:) Да, они это не называют потоками, но по сути это фактически почти тоже самое имхо...
Твоя пропаганда XML как замене многопоточности в FS напоминает мне пропаганду адептов МИРа... Они считали что древовидная структура не нужна раз есть МИР...:) На самом деле XML ничуть не противоричит многопоточности, а прекрасно дополняет ее. Скажем так - на своей тачке удобней использовать многопоточные форматы документов (если так можно сказать), а для обмена между компами - XML. При правильной организации дела это мобилизует пользователей и не дает им возможности развернуть широкий обмен файлами с закрытыми форматами а-ля .doc...:)

Гы. :) Вот уж точно за деревьями леса не увидели. :)

Обратите внимание, что Ирси никого не попытался задеть в последнем сообщении и, если подумать, сказал в 1-2-3-4 по сути дельные вещи. :) Или Ирси --- враг, и поэтому всегда гонит чушь? :)))

В предыдущем моем сообщении "последнем" читаем как "предпоследнем" :)

Ну вот, наконец вспомнил про NT :) Сейчас разговор пойдет по известному шаблону - "Почему Россия не Китай, почему Linux не NT"...

Ладна, эта-а, а физически как твой многопоточный файл выглядит-то?!

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

С чего ты взял, что я пропагандирую XML, а МИР - это что такое?!

Мне просто хочется понять - ты с потоками также путаешься как с цветами (где 'модель', где 'цв. координаты', а где 'кодирование') или нет?!

2CybOrc:

Вверху поста есть ссылочка "[Удалить]" - она работает, когда хочешь чего поправить...

2speer: ну ладно - согласен с тем что цветовая модель CMYK обладает более широким охватом я маху дал, не подумал, бывает...:) Она просто другаz... Классический пример - изобрази чиcто-голубой цвет в RGB...:) Ну а ты про Lab почитал, память освежил? :)
Кстати, почему я должен не вспоминать NT? Мне, в отличае от некоторых, религия не запрещают юзать ту ОС, которая мне наиболее удобна для решения данной, конкретной задачи...:) Образно говоря - вопросы кошерности меня всегда волновали мало, и я с удовольствием ем как и свинину с мацой...;) К тому же нтя изначально делалась на неплохой базе (VMS), в ее разработки принимал участие дековский народ - имхо это о чем-то говорит...;) Да и идей из мира юникса в ней не мало - такие слова как COFF, Kerberos, LDAP, Veritas Software и тд. надеюсь тебе о чем-то говорят? :)
И разумеется из всего кол-ва ОС, которые я привел в пример ты как настоящий линуксоид заметил только NT...;))) С остальными видно не сталкивался? ;)

Ладно, это все лирика была, теперь к делу...
Сами по себе, с точки зрения структур данных, потоки, например в ext2fs, реализуются довольно просто - фактически это небольшая модификация формата записи в каталоге, после которой она получает возможность ссылаться не на одну i-node, а на много. Как это делать конкретно я думаю рассказывать не надо...:) Поток с номером 0 (или один - как считать, яб считал с нуля) это обычная ссылка на i-node, про которую знает весь современный софт. Он и продолжает работать с этим потоком, ничего не зная о других... Понятно что утилитки для работы с fs (chkdsk и прочие) придется модифицировать чтоб они знали о существовании потоков, но это дело привычное и несложное имхо, это все понятно и неинтересно, рутина...:)
А вот со стратегией выделений блоков ты правильно подметил - она достаточно серьезно усложняется... Теперь надо заботится чтоб не только поток был как можно менее фрагментирован, но и чтоб потоки собирались как можно ближе друг к другу... В принципе мэти мехамизмы достаточно хорошо изветсны и если поискать в инете, то имхо статьи на эту тему найти несложно... Мне если честно лень это делать...:)
Разумеется ты также прав в том что большое кол-во потоков имеет смысл плодить разве что при реализации БД, в остальных случаях это может дать негативные результаты. Имхо из "стандартных" потков следует зарезервировать следующие:
1. Один поток на реализацию ACL. В зависимости от реализации в нем будут храниться разные данне в разном формате. Имхо это нестрашно что он один на все ибо две системы ACL одновременно использовать врятли кому-нибуть в голову придет :)
2. Второй поток на данные о типе файла, его обработчике и прочих параметров, общих для любого гуя...
3. Третий поток яб зарезервировал для хранения ресурсов исполнимого файла, типа описания менюшек, диалоговых окон, текстовых сообщений и т.д. Это очень удобно к слову и поскольку позволяет их модифицировать без перекомпиляции, то дисциплинирует программера, заставляет его писать более правильный код и например не забывать о возможностях различных переполнений. :)
Далее идут потоки спорной необходимости, типа содержащих общую инфу об авторе документа и т.д. (такие данные помогают в поиске нужного документа по файловым свалкам), поток, содержащий инфу с описанием форматов всех остальных потоков (а оно надо? не знаю, хотя для реализации продвинутых журналов имхо пригодилось бы наверное, для тех что могут гарантировать не только целость самой FS, но и целостьно данных хранящихся в ней), данных специфичных для KDE & GNOME...
И и на закуску потоки с данными пользовательских приложений, как например поток форматированием для текстового редактора...
Фактически выходит что никак не более 10ти потоков нужно, если на БД не закладываться...
Напоследок - к слову меня очень порадовало как в RaiserFS попытались частично преодолеть врожденную убогость архитектур, основанных на plain kernel... Дело в том что в отличае от микрокернольной архитектуры, plain kernel не позволяет легко и просто реализовать такие фичи как например поддержку ACL, отличную от общепринятой ибо слишком много приходится править в самом ядре... Так вот - они решили использовать плагины в fs...:) Это действительно решает проблему, но блин как в анекдоте "удалять гланды, электродом, через ж@пу"...:) Хотя это действительно решение и пожалуй единственно-возможное для plain kernel...

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

Kerberos и NT? Это была издевка? :)

2CybOrc: можно и имена... Но получается очень эээ... неоптимально...:( С номерами все ясно - номер потока соответствует его порядковому номеру в списке ссылок на i-node в записи каталога... А имена... Ну я говорил о потоке, содержащим инфу о формате данных во всех остальных потоков, если его вводить, то там можно и имена задовать...:) Кстати наличае этого потока решает проблему с неправильной интерпретацией содержимого потока приложениями...
Это не издевка - нтя использует эээ... "улучшенный" керберос :) Имхо правильно говорить - модифицированный или протокол, разработанный на его основе скорей...:)
AD вообщем-то тот же LDAP с добавкой из фирменных примочек... Формат исполнимого файла - расширенный вариант COFF... Динамические тома - никто и не скрвает что это лицензированно у Veritas Softvare, имхо это название хорошо знакомо всем, работавшим с коммерческими юниксами...:)

С именами просто попроще организовать расширябельность системы, чем с номерами. Вероятность того, что каким-нибудь двум девелоперам понравится одно и то же число почему-то мне кажется более высоким, чем придумать два одинаковых имени. :)

Просто с Керберос, помнится, скандал даже был. Вот то-то у MS и плохо, что берут стандарт и делают его слабо совместимым с оригиналом. Керберос-то не первый пример. До того был скандал с Java, например. Не скажу, что этим только MS страдает (война браузеров тому пример). Но у MS видно четче, у них даже разные версии Word'а слабо совместимы (знаю одну конторку, в которой у сотрудников стоят Word 95 и 97 для совместимости со всеми клиентами).

Хм... У меня тут вопрос по CMYK возник: мне всегда казалось, что у CMYK одна компонента должна быть нулевой всегда из-за избыточности системы (черный цвет эмулируется тремя другими компонентами). Это возникло из-за неидеальности CMY при создании черного цвета и элементарной дешевизны черной краски по сравнению с цветными компонентами. Возможно, я что-то недопонимал? Кажется, CMYK из CMY получался выбором минимального по значению компонента из CMY (допустим, m), потом CMY отображалась примерно таким образом:

(C, M, Y) => (C - m, M - m, Y - m, m)

Биекция, однако. Значит, 2^24, а не 2^32. В случае, если в каком-то цвете CMYK (по такой логике) все компоненты отличны от нуля, то такой цвет (C, M, Y, K) входит в класс эквивалентности с цветом (C - m, M - m, Y - m, K + m), где m = min(C, M, Y). Вот формул перевода из RGB в CMY уже не помню. Но, если точное обратное преобразование не получается, то прямое тоже не будет точным из-за равенства мощностей множеств цветов. Тогда дефекты должны появляться и в прямом преобразовании (впрочем, тут я нигде не учитываю особенностей человеческого зрения). Может, кто-нибудь что-то объяснит?

2CybOrc: ну а как эти имена хранить? Боюсь что орентация на первичность имени сильно замедлит все и сведет все преимущества на нет...