Все новости от 8 августа 2004 г.

Взлет и падение империи Wintel

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

Вообразите, что вы — продакт-менеджер по Windows. Вот однажды вы просыпаетесь и слышите, как аналитики и конкуренты говорят, что Linux начинает вторгаться на десктопы. Между тем настольная Linux не может состояться уже несколько лет. Ваше финансовое положение лучше всего того, о чем вы мечтали в колледже. Но в то же время вы видите мало благоприятных возможностей для быстрого дальнейшего внутреннего продвижения или ухода на сторону.

Взяться за трудный проект? Не-а. Лучше я просто останусь дома, схрумкаю коробку Frosted Mini-Wheats и посмотрю телемарафон Wacky Races.

Губительное чувство паралича от успеха — одна из главных тем знаменитой «Истории упадка и гибели Римской империи» Эдуарда Гиббона, пожалуй, лучшей книги о развале крупных организаций. (Тодд Немет, инженер из Google, прислал эту иногда работающую ссылку, где можно проверить, каким императором вы могли бы стать).

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

«Первые семь столетий были заполнены чередой триумфов; наконец Августу пришла мысль отказаться от амбиций покорения всей земли и вселить в народных консулов дух умеренности, — пишет Гиббон. — Расположенный к миру в силу своего характера и ситуации, он быстро обнаружил, что Риму в его теперешнем экзальтированном состоянии следует не столько полагаться на оружие, сколько опасаться его; и что в условии непрерывных войн на далеких рубежах действовать с каждым днем становится все труднее, результаты получаются все более сомнительными, а владения расшатываются и приносят все меньше доходов».

Microsoft и Intel, как древний Рим, засасывает трясина беспросветности. Microsoft пытается внедрить в Longhorn довольно элегантную технологию поиска и динамичный интерфейс. Она хочет расширить границы Windows, добавив поддержку 64-битного ПО. Помимо этого, команды инженеров работают над игровыми консолями, ПО для сотовых телефонов и над усовершенствованием телевидения.

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

Intel, со своей стороны, задерживает ряд проектов для серверов, настольных ПК и ноутбуков. Тем временем телекоммуникационное подразделение компании продолжает терять деньги, и замышленный в 2000 году план обойти Texas Instruments в области сотовых телефонов постепенно свернут. В прошлом году Intel пыталась выдоить больше денег из своего отделения флэш-памяти, но вместо этого только растеряла заказчиков.

У периферийных подразделений дела идут лучше, чем у штаб-квартир. Базовая архитектура Intel Pentium 4, разработанная в США, выделяет слишком много тепла; от версии, которую планировалось выпустить в будущем году, пришлось отказаться. Зато израильская группа создала успешный Pentium M для ноутбуков. В 2006-2007 годах концепции этой лаборатории лягут в основу настольных чипов.

Естественно, что и Intel, и Microsoft представляют ситуацию в противоположном свете. Longhorn — гораздо более радикальное обновление, чем три прошлых версии Windows. В какой-то мере он сродни Windows 95, которую тоже несколько раз задерживали, но которая в корне изменила облик рабочего стола.

Более того, в последние полтора года Microsoft предпринимает попытки наладить международные отношения, что позволило бы ей возвести бастион против Linux на рынках развивающихся стран. Сейчас в компании около 600 сотрудников занимают посты с названиями типа national technical officer и public sector director и снабжают государственных чиновников таких стран, как Бразилия, информацией по вопросам просвещения в области ПО и законодательства в сфере торговли и интеллектуальной собственности.

Программы помощи другим странам часто вызывают шок в США и Европе, но Иордании или Польше, которые стремятся приобщиться к глобализации, помощь, конечно, не помешает. «Мы показываем им, как надо развивать местную софтверную индустрию», — говорит старший вице-президент отделения госсектора Microsoft Мэгги Уилдероттер.

Последние проблемы Intel, конечно, бледнеют по сравнению с отзывами продуктов и связанными с Rambus промахами 2000 года. Трудно отрицать и то, что персонал обеих компаний отличается высоким интеллектуальным уровнем и в целом конкурентоспособен.

И все же проблема размеров остается. Даже с хорошо организованной, гиперактивной рабочей силой Microsoft и Intel придется столкнуться с реальностью ведения войны на три или четыре фронта. «Intel демонстрирует все признаки попыток ускорить свой прогресс путем увеличения числа людей, занятых в каждом новом проекте, — писал в начале этой недели аналитик Raymond James Ашок Кумар. — Похоже, что эта стратегия достигла точки обратного эффекта».

В Риме обстоятельства со временем пересилили таланты. Смерть последнего великого императора Феодосия в 395 году привела к разделу империи между его сыновьями Аркадием и Гонорием. «У Гонория не было страстей, а следовательно и дарований, — отмечает Гиббон. — Вскоре он отказался (официально) от своих территорий, и серьезным и повседневным занятием монарха Запада, который поручил управление империей твердой и умелой руке своего полководца Стилихона, стало развлечение кормлением домашней птицы».

Обе компании сильны, но если вы застанете Стива Баллмера за кормлением цыплят, то конец, вероятно, уже совсем близок.

 В продолжение темы:

Обсуждение и комментарии

	Прохожий 9 Aug 2004 2:03 PM
Да уж... Хоронили их (MS & Intel), хоронили... А воз и ныне там. Полагаю, ситуация с их доминированием изменится, когда наступит очередная "точка стратегического перегиба" самими технологиями компьютинга с) Энди Гроув, - например, появится нормальный речевой интефейс - да и то, если ровнехонько в этот момент на рынке случится новый Гейтс, который будет действовать абсолютно правильно и видеть на 15 лет вперед. А просто проблемы масштабов... они давно научились с ними справляться, речь лишь о более или менее высокой норме прибыли или темпах роста - на далеко не о катастрофе. Фантазия у товарища автора разыгралась :-).
	+++ 9 Aug 2004 3:30 PM
Да уж... Хоронили их (Sun и SGI), хоронили... А воз и ныне там.
	нц 9 Aug 2004 4:05 PM
редкостная бредятина
	Dr_Zuzumbo 9 Aug 2004 5:15 PM
Da uzh xoronili CCCP i ... poxoronili!!!
	Tre 9 Aug 2004 7:34 PM
Начал читать - прочитал 2 абзаца, .... чтобы меня такой паралич от успеха хватил:))) дальше етот бред читать не смог
	DEFILER 9 Aug 2004 8:13 PM
Нет, все-таки Wintel must die! Нового Гейтса не будет, будет разве что новый Митник, Саддам, Усама, ...
	Skull - sibskullmail.ru 10 Aug 2004 10:20 AM
2DEFILER: "Нового Гейтса не будет" Посмотрите "Я, робот" - появление нового Гейтса в робототехнике весьма вероятно. Но это приведёт к ещё более устрашающим последствиям, чем нынешняя деятельность Б.Гейтса. Монополия - маст дай! :) P.S. Хороший фильм! Когда свободные горожане мочили роботов, я буквально подпрыгивал на кресле, вскрикивая: "Свободу исходникам! Мочи виндузячие поделки". :))))
	Chkaloff 10 Aug 2004 11:22 AM
2 +++: >Да уж... Хоронили их (Sun и SGI), хоронили... А воз и ныне А что, от прошлого блеска у Sun и SGI мало что осталось. SGI была законодателем мод в компьютерной графке имела собственный процессор и операционную систему, а теперь собирает супер-компьютеры на Itanium под Linux. В новостях особо нигде не мелькает. Sun вот тоже в укор Intel отказалась от 86 архитектуры. В итоге через год всетаки выпустила 86 серверы под Linux уже в укор MS. Самое смешное, что еще через год они поняли, что рубят сук на котором сидят - их серверы под линух покупали не бывшие потребители Windows, а их же самые пользователи, которые теперь хотят тратить меньше. С этим надо что-то делать, и вот они то лакеями к MS идут, то хотят прикупить себе тоже кусочек Linuxа как (примазяться как IBM, HP, Orcale), но пока толком не знают как. Так что и от их былого величия не много осталось.
	777 10 Aug 2004 1:50 PM
2Skull: >подпрыгивал на кресле, вскрикивая: "Свободу исходникам! Мочи виндузячие поделки". И почему я не удивлен .?.
	domician 11 Aug 2004 12:47 AM
2 Skull а предпроигрывание и предпросмотр при наведении курсора как оказалось были еще в Проводнике Вин98... а мне некоторые пытались лапшу вешать, что это типа продвинутая фишка КДЕ, которой в ограниченном Эксплорере ну просто быть не может :) теперь понятно, у кого КДЕшники это передрали
	Wintermute - devnul.ru 11 Aug 2004 9:33 AM
Из дневника Skull'а: "Хоронили Wintel. Порвали два баяна." :)
	CyberStorm 11 Aug 2004 9:51 AM
Ерунда написана. Задержки с выходом продуктов Microsoft вызваны не столь "загниванием" компании, сколько сложностью технологий которые пытается внедрить Microsoft в новом продукте. Думаю что Microsoft понимает, что для того, чтобы пользователи захотели перейти на Longhorn мало нового более красивого интерфейса, нужно нечто большее. Чем качественнее и сложнее продукция выпускаемая сейчас, тем сложнее выпустить новый продукт на замену предшественнику с лучшими характеристиками - думаю для всех это очевидно. Улучшеные на 10-20% потребительские свойства продукта уже не стимулируют потребителя на покупку, требуется как минимум улучшения в разы :)
	Shadow 11 Aug 2004 10:45 AM
> мало нового более красивого IMHO, это всё равно обеспечит более чем неплохой уровень продаж %)
	CyberStorm 11 Aug 2004 12:55 PM
Shadow - на корпоративных клиентов этот стимул (я имею ввиду интерфейс) не действует ;)
	dr-Wicked 11 Aug 2004 2:34 PM
Тупость статьи в том, что юноша не понял главного. Молодость Делает задел, расставляет вешки. А от продукта требуют зрелости. Романтика 30 часового программирования при промышленном производстве не уместна. Она хороша в рассказах типа "крутой росейский програмер Вася Пупкин в очередной раз заставил содрогнуться Microsoft… от смеха"
	Serge 11 Aug 2004 2:59 PM
Основной тезис статьи - "Большой размер корпорации приводит к неэффективной работе" спорен... Он основывается на том, что в больших системах постоянно присутствующая на всех стадиях энтропия (беспорядок) имеет тенденцию к нарастанию (второй закон термодинамики). Однако, все мы знаем, что использование цифровых технологий позволяет положить конец шуму при передаче информации. Соответственно, с помощью компьютеров можно организовать слаженную работу больших, даже огромных коллективов. Поэтому размер корпорации не обязательно недостаток. Более того, когда вместе собираются умные люди, то это имеете коммулятивный эффект. Среди умных сам становишься умнее. То, что MS почивает на лаврах, тоже, по моему неверно. Чего стоят разработки: файловой системы WinFX c XML схемами данных вместо старых папок и файлов как сейчас, интерфейса пользователя на XAML и инфраструктуры распределенных транзакций Indigo?
	Прохожий 11 Aug 2004 3:31 PM
Статья похожа на сеанс самопсихоаналитики. Скорее всего Автор сам страдает от проблемы "застойной воды", которая зачастую присуща большим корпоративным культурам и нашего отечественного рынка тоже. Почивать на лаврах служащему Майкрософта, как и Интела или любой другой большой ИТ-компании не дадут: специфика их контрактной работы в том, что он проходит каждые 3-месяца переатестовку, включающую достижение определенных поставленных задач. Отдохнуть можно - но не очень долго :)) Не случайно, был аналитический обзор, который говорит, что ИТ-работник в более мелких компаниях, зачастую имеет и больший оклад и более комфортабельные (не враждебные) условия работы, и привязываются к нему в маленьких фирмах значительно сильнее. По-этому "выживет только пароноик" :))) .... Насчет развития или будущности компаний, можно было бы сказать следующее: на мой взгляд их проблемы отражают общую проблему нашего глобального социума - технологии развились и могут развиваться еще достаточно круто, но эффекта их применения от этого не видно. Не случайно, тот же Интел, IBM и ряд других компаний инвестируют в настоящее время больше денег в поиск ответа на вопрос "А зачем это все надо?", нежели в разработку и производство как таковые.
	Andy 11 Aug 2004 5:14 PM
2drWicked: так-то оно так, но если на одного тестера приходится три программера и семь продакшн-менеджеров, то это уже признак зрелости?
	Andy 11 Aug 2004 5:19 PM
2SergeL "Чего стоят разработки: файловой системы WinFX c XML схемами данных вместо старых папок и файлов как сейчас" нечто подобное, афаир, уже было разработано в конце восьмидесятых. "интерфейса пользователя на XAML" a-la Quartz? "и инфраструктуры распределенных транзакций Indigo?" a-la Rendevouz? Да, ресоздание технологий - тоже в каком-то роде инновации.
	Andy 11 Aug 2004 5:21 PM
2Прохожий: "Почивать на лаврах служащему Майкрософта, как и Интела или любой другой большой ИТ-компании не дадут" рядовой-то служащий может пыхтеть как паровоз над своим куском работы, который через полгода будет благополучно выкинут за ненадобностью ввиду изменения генеральной линии партии.
	erewrewrewrewrew 11 Aug 2004 6:14 PM
2Andy Да, ресоздание технологий - тоже в каком-то роде инновации. Andy так не терпелось взобраться на любимого конька, что он даже не обратил внимания на отсутствие слова инновации в исходной фразе "Чего стоят разработки". Если нечто в этом духе кто-то делал в 80-х, это еще не значит, что сегодня такой софт не нужно разрабатывать для того, чтобы продать завтра. И вообще, Мефистофель в переводе Пастернака говаривал "Когда б ты знал: нет мысли мало-мальской, Которой бы не знали до тебя!"
	Chkaloff 11 Aug 2004 6:14 PM
2 Adny: Если вы про Apple Quartz, то не потрудитесь ли вы объяснить какую параллель вы умудрились провести с XAML? Если вы про TIBCO Rendevouz то уж аналогом ее является скорее MS MSMQ, IBM MQSeries. Какое отношение имеет к Indigo? На счет WinFS. Даже МС к этой проблемме подходит уже более 10 лет. Еще в NT4 они собирались вводить так называемую Object File System. Тогда у них уже появились задумки на этот счет. Но вот только в лонгхорне им суждено, вероятно, реализовать часть этой идеи. Что же касается того, что было разработано в конце 80тых, то похоже ни вы не помните как это называется, ни все остальные. Ну, если оно такое крутое было, то где оно сейчас? А если MS сделает WinFS, а через 5 лет им будет все пользоваться, а через 3 года Linux начнет подобное делать, то кто мудак? Время покажет, а разговоры типа, они стырили наши идеи и реализовали - очень напоминает разговоры неудачников.
	Serge 11 Aug 2004 6:30 PM
2 erewrewrewrewrew Я знаю другую цитату: "Красивые идеи как красивые женщины - обычно уже замужем" (Л. Ландау)
	Пётр 12 Aug 2004 9:32 AM
а как же ИБМ. Вроде бы немалая корпорация. И был в ней в какой-то момент упадок, да вот нет, напряглись. И раз в три месяца отчитывались о работе сотрудники и продажи ихние расти начали и изобретать они меньше не стали. И как-то не видать чтобы они загнивали.
	00alex 12 Aug 2004 11:03 AM
2 Serge: > Однако, все мы знаем, что использование цифровых технологий > позволяет положить конец шуму при передаче информации. Ну положим, ЭТО знают не все. Некоторые знают ровно обратное. Что никакие цифровые технологи и любые другие технологии, даже ещё не изобретенные, но основанные на известных СЕГОДНЯ законах физики, НЕ могут положить конец шуму. Шум можно только снизить. В качестве примера, я где-то совсем недавно услышал: Возьмем аналоговый и цифровой телевизор, всем ясно, что цифровой телевизор обеспечивает лучшую картинку. Но стоит сигналу (аналоговому, а все передается аналоговыми сигналами) зашумится, и цифровая информация становится нераскодируемой. Как следствие телевизор не показывает ВООБЩЕ НИЧЕГО. В это время, аналоговый спокойно передавал бы картинку и звук, пусть и с помехами. Автором поднят главный принцип: большим империям свойственно распадаться. И чем больше империя, тем внезапнее это может произойти. Почему? Если внешние условия резко изменятся, то большая империя дольше адаптируется, чем маленькие единицы. Зато у империи есть преимущество над единицами, оно может влиять на внешнее окружение. Но если на формирование внешнего окружения тратится сил больше, чем адаптироваться под него каждой единице в отдельности, то имерия переходит в неустойчивое состояние и может распасться. В действительности мы могли наблюдать как Майкрософт и Интел, не раз адаптировались сами, ну а формирование ими окружающей их среды, вообще происходит постоянно :) ИМХО. Майкл правильно схватил идею, но до распада, возможно, ещё очень далеко. Ни Майкрософт ни Интел не относятся к неповоротливым Империям. Они одни из наиболее динамичных Империй.
	Z$ 12 Aug 2004 11:44 AM
Ну, если оно такое крутое было, то где оно сейчас? А если MS сделает WinFS, а через 5 лет им будет все пользоваться, а через 3 года Linux начнет подобное делать, то кто мудак? --- оно здесь Oracle File System уже 5-10 лет :)
	Dr_Zuzumbo 12 Aug 2004 11:46 AM
Chkaloff, Не TIBCO Rendevouz, а APPLE Rendezvues
	dr-Wicked 12 Aug 2004 12:12 PM
2 Andy Компании обычно продают програмный продукт (те о которых мы говорим). Не пишут "ценные сорцы" в назидание потомкам, а продают товар. Вполне возможно, что именно такой должна быть структура компании. Конечно в управлении всегда есть место для усовершенствования.
	Serge 12 Aug 2004 12:18 PM
2 00alex В этом самая суть. При передаче пакетов из 0 и 1 с контрольной суммой (хешом, цифровой подписью) можно гарантировать, что приняли именно ту информацию, которую нам передавали. Или не приняли ничего - кривые пакеты отбрасываем и требуем их передать снова. При таком протоколе передачи шум не появляется в принципе. На этом основана работоспособность всей компьютерной техники. И именно поэтому мы можем свободно обращаться с гигабайтами информации. Представьте чтобы было, если бы при передаче команд из памяти в процессой некоторые биты чуть чуть менялись бы... Я и хочу сказать, компьютерная техника может положить конец присутствию шума в больших системах. Теперь посмотрим на корпорацию как на тот же процессор (подробнее вскоре можно будет посмотреть на сайте megasoftware.com.ru - дня через 3-4), который обрабатывает информацию (в данном случае планы работ, задания отделам и отдельным работникам). Сейчас это аналоговая машина. В ней присутствует шум - кто то чего то не понял, кто то чего то не сделал вовремя. Если перейти на цифровое управление и в корпорации (внедрить системы управления производством), что наверняка давно сделали Microsoft (насколько я знаю там года 4 назад внедряли SAP), то отрицательное влияние больших размеров можно свести к минимуму, а положительные приумножить.
	00alex 12 Aug 2004 1:25 PM
2Serge: И да и нет. 1) "можно гарантировать, что приняли именно ту информацию, которую нам передавали" ДА, под гарантией понимается исчезающе малая вероятность ошибки 2) "При таком протоколе передачи шум не появляется в принципе" Да, если не считать шумом "отбрасываемые" пакеты. 3) "компьютерная техника может положить конец присутствию шума в больших системах" Да, только в тех системах, где нет человека. И то, со временем, эти системы все-равно будут деградировать (работает вероятностный принцип). Но можно сделать систему, которая будет надежно работать в течение наперед заданного периода времени. 4) "Теперь посмотрим на корпорацию как на тот же процессор ... Сейчас это аналоговая машина" И слава богу! Поэтому она работает всегда! Даже когда отключают электричество!!! ;-) Если все зашить жестко в цифру (описать четкие полномочия), то такая система не будет гибкой и не сможет адаптироваться к изменяющимся условиям внешней среды. А если эти правила менять постоянно, то вот уже и "аналоговость" ;-) кто проконтроллирует контроллера, который контроллирует правильность и бесконфликтность новых правил? :))) Подытоживая, цифра - не панацея, она помогает оптимизировать часть решения задачи, или лучше сказать - определенный вид задач.
	Chkaloff 12 Aug 2004 1:26 PM
2 Z$: >оно здесь Oracle File System уже 5-10 лет :) Ну и где она на десктопе, чтобы реальную пользу приносило? Даже поиска на сайте Orcale похоже про это не слышал :-) http://www.oracle.com/webapps/search/search.do?group=OCOM&g roup=CUSTOM_APPS&keyword=%22Oracle+File+System%22
	Chkaloff 12 Aug 2004 1:39 PM
2 Dr_Zuzumbo: А ссылочку можно? А сайт www.apple.com похоже ничего про это не знает. Жаль у них там post. И гугл ничего не знает. http://www.google.ru/search?hl=ru&ie=UTF-8&q=APPLE+Rendezvue s&lr= :-) А вот для "Apple Rendevouz" гугл нашел в интернете аж 32 ссылки. apple.com продолжает быть не в курсе про это. Наверное гениальная технология. Это знание наверное доступно избранным, в отличии от WinFS ~52000 ссылок.
	Z$ 12 Aug 2004 2:11 PM
2Chkaloff http://www.oracle.com/technology/products/ofiles/index.html вы гугл не освоили ;) >Ну и где она на десктопе, чтобы реальную пользу приносило? глупый вопрос - ваша кантора чем занимается ? а то как бы есть такая традиция хранить файлы на сервере :) вы были не в курсе ?
	Dr_Zuzumbo 12 Aug 2004 2:12 PM
Chkaloff, Tibco i Apple uladili svoi spor o tovarnom znake Rendezvous. inet polon ssilkami ob etom, no eto izhe iz drugoi peni, a dlia togo chtobi poniat o chem idet rech prochti eto: К оперативной информации относятся и сведения о расположении корректного PPD-файла. При замене сетевого принтера они тоже обновляются. Распознав компьютер по имени хоста, Rendezvous ищет необходимый для его работы PPD-файл. В mDNS-таблицу заносится путь к этому файлу и связывается со всеми остальными компонентами, объединенными под сервисным именем. При обращении к службе печати, а через сервисное имя -- к конкретному принтеру mDNS указывает, какой именно из PPD-файлов будет использован приложением Print Center в работе. Если в сети несколько принтеров, технология Rendezvous избавит пользователя от необходимости выбора PPD-файла, автоматически указав нужный. Новое устройство объявляет о своих сервисах в специальном уведомлении, которое рассылается всем абонентам сети. Происходит это с помощью обмена сообщениями со службой mDNS. Каждое из устройств посылает в сеть текстовый файл, содержащий всю необходимую для обнаружения сервиса информацию. Эти сведения заносятся в таблицы mDNS на всех машинах сети. Теперь, чтобы найти необходимый сервис, нужно обратиться к записям указателя на своем компьютере и через них связаться с устройством, которое его предоставляет. Пользователь получает доступ к службам Rendezvous через оконные броузеры сервисов. Обращаясь к тому или иному окну, он выбирает тип сервиса. Для выхода в сеть и связи с другими машинами следует применять http-броузер, для подключения к удаленным компьютерам и совместного использования файлов -- ftp-броузер, для использования служб печати -- printer-броузер и т. д. Если в броузере службы нет необходимого имени, значит устройство на данный момент недоступно. Снова подключившись к сети, оно предложит свои услуги, появившись в оконном интерфейсе. Максимальное число устройств в сети, построенной по технологии Rendezvous, не должно превышать 1300, хотя адресовать можно гораздо больше. Значительное количество компьютеров увеличивает время автоматической конфигурации и сильно замедляет обмен данных. В реальной жизни такое число подключений к локальной сети практически не встречается. В крайнем случае большую сеть можно разделить на несколько подсетей со своими системами "нулевой" конфигурации. Разумеется, корпоративная сеть, построенная с применением Rendezvous, нуждается в дополнительной настройке со стороны системного администратора, а принцип "нулевого" конфигурирования не удовлетворяет корпоративным требованиям к безопасности сетей. Уже сегодня технология Rendezvous широко используется. О ее поддержке заявили многие компании, выпускающие компьютерную периферию и бытовую электронику. Более десяти производителей принтеров, в том числе Canon, Epson, Hewlett-Packard, Lexmark и Xerox, намерены внедрять ее в свои устройства, что позволит быстрее устанавливать и эффективнее использовать службу печати. Philips будет выпускать Rendezvous-совместимые мультимедийные устройства -- телевизоры для просмотра компьютерного видео и музыкальные центры для проигрывания звуковых файлов.
	Dr_Zuzumbo 12 Aug 2004 2:15 PM
Далее определяются тип сервиса устройства и номер порта, по которому работает обслуживание. Все хосты распределяются по типам сервисов, объединяющим службы одного вида. Название разновидности обслуживания, которое устройство предлагает абонентам сети, вносится в mDNS-таблицу. Так, например, тип обслуживания _http._tcp. предназначается для связи с другими компьютерами с помощью протокола tcp. Под записью _ipp._tcp. находятся все службы, предоставляющие услуги печати, которые реализуют принтеры. Номера портов бывают как жестко закрепленными за отдельными сервисами (например, порт номер 80 за Web-службами), так и произвольно выбираемыми. И номер порта, и тип службы проверяются на уникальность в локальной сети. Затем происходит выбор сервисного имени -- ключевого для Rendezvous-сети. Оно содержит всю информацию, необходимую для адресования. Пользователь работает только с сервисным именем, а уже от него идет запрос mDNS об имени хоста, адресе и номере порта. Такая система имеет свои преимущества. Во-первых, обслуживание обозначается более удобочитаемым именем, чем доменное. Во-вторых, гарантируется возможность обращения к службе при изменении всей необходимой информации. Сервисное имя служит устойчивым идентификатором для данного типа обслуживания, символизируя сокетную связь между двумя точками сети. Оно предохраняет пользователя от повторного выбора устройства при изменении номера порта, IP-адреса или имени последнего. Пока обслуживание по определенному сервисному имени используется, сохраняется информация о сокете, то есть открытие службы происходит лишь однажды, при первом подключении устройства к сети. В дальнейшем, даже после временного отключения, устройство будет готово к работе без затрат времени на начальную установку. Сокетная связь помогает соотносить старые и новые номера портов, IP-адреса и DNS-имена, необходимые для правильной адресации, а также позволяет совершать "подмену" этой информации. Сервисное имя также проверяется на пересечение со всеми устройствами. Наконец, когда требуемая информация собрана, заполняются все разделы mDNS-таблицы. Она хранится в каждом из компьютеров локальной сети. Строка Pointer Records указывает на тип сервиса, к которому относится сервисное имя. Она дает возможность обнаружить службу, предоставленную конкретным устройством, через общий тип подобных услуг. Эту информацию видит пользователь в оконном интерфейсе и непосредственно с ней работает. Запись Service Records связывает сервисное имя с именем хоста, а через него с номером порта и IP-адресом. Также здесь находятся сведения о трафике, выделенном данному устройству, и указание на приоритетность этой связи в сети. Строка Text Records дополняет имеющуюся информацию о типе конкретного сервиса и содержит добавочные сведения, необходимые для открытия службы. Она оповещает о доступности пользователя ("доступный", "находящийся вне сети"), указывает на приоритетность использования принтера ("по умолчанию", "по выбору пользователя") и т. п. Кроме записей, в mDNS-таблицу заносится оперативная информация: сведения о номере порта, имени хоста и IP-адресе. В случае необходимости, если произошла замена сетевого устройства, эти данные соответственно обновятся. Устойчива лишь их связь с сервисной записью, указывающей на вид услуг, которые предоставляет устройством. Все "подмены" выполняются автоматически, без малейшего вмешательства пользователя.
	Dr_Zuzumbo 12 Aug 2004 2:15 PM
В сети без выделенного сервера генерирование IP-адресов, подбор DNS-имен, обнаружение типов сервисов обычно сильно загружают канал и занимают относительно много времени, но Rendezvous сводит необходимый для конфигурирования трафик к минимуму. Для этого разработана целая система мер. Полученная при конфигурировании информация хранится в специальном кэше -- если она понадобится в следующий раз, то не нужно будет повторять запрос. После каждого опроса создается список ответивших хостов, а затем на наличие новых служб опрашиваются только устройства, отсутствующие в данном списке. Это предотвращает повторные ответы, которые не несут полезной информации, а лишь дублируют друг друга. Наконец, опрос сети на подтверждение доступности сервисов ведется не постоянно, как это делал Apple Talk, а через определенные промежутки времени, возрастающие в геометрической последовательности. Точно так же новые службы, появившись в сети, объявляют о своем присутствии с интервалом в 1, 2, 4, 8, 64 и 4096 секунд. Таким образом, "фоновый шум", необходимый для первоначальной конфигурации и поддержки работоспособности, заметно уменьшается. Все это разгружает сеть. Предоставление сетевых служб по технологии Rendezvous состоит из выбора IP-адреса, объявления сервиса, просмотра доступных служб сети, а также создания устойчивой связи между обслуживанием и необходимой для адресации информацией. Номер сетевого адреса генерируется в самом подключаемом устройстве. При этом не используются псевдослучайные алгоритмы, опирающиеся на общие для всех данные, например на календарь и счетчик времени. Цифровые значения выбираются случайно из числа отведенных под Rendezvous адресов, которых более 65 тысяч. После того как адрес выбран, он проверяется на уникальность. Если компьютер находит свой адрес уже использованным, то в действие вступают механизмы улаживания конфликтов пересечения. Перед выключением компьютера список контактов сохраняется -- включив машину в следующий раз, не нужно тратить время на выбор адреса и заниматься его проверкой. Решив проблему адресации, устройство готово получать и отправлять данные по сети. Но пользователю удобнее работать не с числовыми IP-адресами, а с именами узлов. Для наименования Rendezvous использует вариант стандартной службы DNS, который называется multicast (mDNS), и создает таблицу, соотносящую IP-адреса с именами хостов. Для устройств имя находится автоматически, для клиентских машин --запрашивается у пользователя. Уже имея IP-адрес, mDNS-устройство посылает запрос на использование уникального имени. После проверки его уникальности устройство присваивает это имя себе.
	Dr_Zuzumbo 12 Aug 2004 2:16 PM
В одноранговой локальной сети заголовки сетевых пакетов не модифицируются при передаче данных от одного хоста к другому, а сохраняют свой первоначальный неформатированный вид. Здесь не используется служба DHCP, которая занимается распределением адресов и параметров начальной настройки между клиентами сети. Взамен нее предлагается собственная система динамического распределения адресов, соотнесенных с именами устройств. Система имен Rendezvous тесно связана с DNS и не заменяет ее, а лишь дополняет на локальном уровне. Имена всех входящих в такую сеть устройств объединены в суффиксальную группу local, которая не является доменом в полном смысле этого слова. Отличие в том, что доменные имена глобально уникальны, а имена служб Rendezvous -- только на своем собственном локальном уровне. В глобальной или большой внутренней сети, состоящей из нескольких локальных, одинаковые имена с суффиксом local. вполне могут повторяться на разных участках. Они проверяются на пересечение только в пределах своей локальной сети. Система имен Rendezvous предполагает разделение сетевых объектов на пользовательские компьютеры и ресурсы. Для того чтобы отличить услуги от имен хостов, в ресурсных записях сервисы отмечены префиксами символа подчеркивания. После имени сервиса указывается название транспортного протокола, по которому идет обслуживание. Строка в DNS-таблице имеет вид _<имя сервиса>. _<транспортный протокол>, например _ftp._udp. Пользовательские компьютеры тоже отражены в ресурсных записях, поскольку они предоставляют услугу доступа к своим файлам, предназначенным для совместного использования. Запись об этой службе выглядит как _http._tcp. Но особенности технологии Rendezvous не исчерпываются распределением IP-адресов и нумерацией портов, а также адресованием по пользовательскому имени. Она обеспечивает надежную работу всех сетевых служб при изменениях IP-адресов, нумерации портов и DNS-имен устройств, на которых эти службы выполняются. Такое нередко случается в "гибких" сетях с непостоянным количеством хостов, где мобильные пользователи периодически отключаются и снова подключаются и где регулярно появляются новые устройства, зачастую без ведома администратора. Rendezvous рассматривает сеть не как объединение компьютеров и устройств, а как набор служб, реализуемых соответствующими устройствами. Пользовательский интерфейс IP-сетей, построенных по технологии Rendezvous, ориентируется не на присутствующие в сети хосты, состав которых может изменяться, а на доступные пользователю в данный момент службы. "Традиционный", опирающийся на хосты, интерфейс оправдывает себя только в "стабильной" сети, где одни и те же сетевые сервисы постоянно предоставляют одни и те же сетевые устройства. В "гибкой" сети, где состав и количество хостов постоянно изменяются, относительно стабильными ориентирами остаются лишь сетевые службы. Это могут быть сервисы печати, сканирования, доступа к совместно используемым базам данных и файлам, выхода в Глобальную Сеть, службы демонстрации слайд-шоу и озвучивания мультимедийных файлов, а также им подобные. При этом в зависимости от текущего состава устройств сети они могут выполняться на совершенно разных хостах. Пользователю "гибкой" сети удобнее непосредственно обратиться к необходимой ему службе, чем опрашивать все устройства об их сервисах, а потом сортировать результаты в поисках нужного обслуживания.
	Dr_Zuzumbo 12 Aug 2004 2:17 PM
Chkaloff, Tibco i Apple uladili svoi spor o tovarnom znake Rendezvous. inet polon ssilkami ob etom, no eto izhe iz drugoi peni, a dlia togo chtobi poniat o chem idet rech prochti eto: Разработки компании Apple Computer всегда отличались простотой использования. Не является исключением и технология Rendezvous, позволяющая строить "к случаю" небольшие IP-сети с поддержкой динамического подключения устройств и автоконфигурации. --- Все технологические новинки операционной системы Mac OS X перечислить нелегко. Переход на Unix-ядро повлек за собой очень большие изменения. В перечень основных новшеств Mac OS Х входит и Rendezvous -- технология построения IP-сетей, предполагающая "горячее" подключение сетевых устройств (компьютеров, принтеров, бытовой техники) и их функционирование без предварительной настройки. Для работы в сети "десятка" предоставляет большой набор различных протоколов и служб, но основным является общепринятый TCP/IP. Протокол, разработанный самой Apple, -- Apple Talk -- поддерживается, однако основным не является. Новая технология от Apple дополняет стандартный TCP/IP привычными для мак-пользователей "удобствами", объединяя его скорость и совместимость с динамическим подключением устройств к сети и автоматической их настройкой. Rendezvous предназначена для локальных сетей без выделенного сервера (одноранговых), не имеющих профессионального администратора для обслуживания и настройки. Здесь некому распределять IP-адреса, связывать их с именами узлов, выделять среди абонентов сети ресурсы -- устройства, способные предоставлять различные сервисы. Подобные сети возникают спонтанно, по необходимости, поэтому называются "импровизированными". Их не нужно долго прокладывать и настраивать, а потом демонтировать -- они строятся мгновенно, а после использования быстро сворачиваются. Импровизированная связь идеальна для мобильных пользователей, образующих сеть каждый раз в новом месте. Такую "моментальную" сеть могут организовать несколько мак-пользователей в студенческой аудитории или конференц-зале, на презентации или в библиотеке. Возможно, это будет подключение к бортовой системе автомобиля или импровизированная сеть между переносными компьютерами в поезде. Осуществляется подключение проволочным соединением Ethernet или с помощью беспроводной связи AirPort -- стандартных и широко поддерживаемых технологий.
	00alex 12 Aug 2004 2:19 PM
2Chkaloff э... а вы чего искали в google? [Rendezvous] - 1 670 000 ссылок [Rendezvous file system] - примерно 83,300 Что это такое не знаю, но если искать "WinFSuck" - то гугл вообще ничего не находит, может Вы название не то подобрали для "Rendezvous" ?
	Chkaloff 12 Aug 2004 2:24 PM
2 Dr_Zuzumbo: Ок, а теперь внимание вопрос. Каккое отношение имеет эта технология интеграции печатающих устройств к технологии разработке сервис-ориентированных приложений аснованной на WebServices? Что конкретно MS стырила? Я понимаю что не вы это заявили, но всеже вы продолжили этот диалог.
	Dr_Zuzumbo 12 Aug 2004 2:55 PM
Chkaloff, prichom tut "pechataiushie ustroistva" , vi opisanie texnologii chitali? tam govoritsia o shirokom spektre ustroistv, a vi chtobi brinizit znachenie etoi texnologii, virivaete s konteskta tolko odno ustroistvo. NE K LICU, Chkaloff!
	Вlack ibm.* 12 Aug 2004 3:52 PM
2 777 нас больше..те нет нас может не больше.. ННО мы не ангажированы те в RedHAT не рабоаем а СИПОЛЬЗУЕМ Linux для себя. PTO вообще не сичтается.. про AS нужно спросить? а ты точно не иммешь ничего от того что MS доминирует..??? сомниваюсь. нет есть реальны фанаты MS ( но они на само деле понимаб все недостатки..Win.. и вклиниваютс в разговр когда Linuxоиды прегибают палку.).
	Chkaloff 12 Aug 2004 5:29 PM
Еще раз спрошу, если не понятно. Какое отношение Rendezvous( технология построения IP-сетей, предполагающая "горячее" подключение сетевых устройств (компьютеров, принтеров, бытовой техники) и их функционирование без предварительной настройки) имеет к технологии вебсервисов Indigo, которые MS собирается внедрить в будующей версии Windows? У меня вопрос только вот собственно про это был. Было заявлено что индиго это a-la Rendevouz. Что MS ничего нового не сделал. Так вот я спрашиваю что MS сотдрал в Rendevouz?
	Chkaloff 12 Aug 2004 5:39 PM
2 00alex: >э... а вы чего искали в google? Я ссылку привел. >Rendezvous file system А это что за зверь?
	Chkaloff 12 Aug 2004 5:43 PM
2 Dr_Zuzumbo: >a vi sluchaino ne eto imeli v vidu? >http://www.apple.ru/webobjects/ Ну это какое-то средство для автоматизации создания вебсервисов. Вот кратко о Indigo: http://msdn.microsoft.com/longhorn/support/lhdevfaq/default .aspx#Indigo Кстати о WinFS там же.
	Z$ 12 Aug 2004 5:52 PM
2Chkaloff так про новизну WinFS у вас еще остались вопросы ? :)
	RIK 12 Aug 2004 11:20 PM
2 Z$ У меня есть вопрос. WinFS - прежде всего стандартная высокоуровневая модель данных. Есть ли это в Oracle Files и если есть - то каким софтом используется?
	Z$ 13 Aug 2004 11:31 AM
2RIK не знаю что такое "высокоуровневая модель" ... OF это просто туча пртоколов сверху над бд - SMB, NFS, AFP, WenDAV, FTP + несколько не принципиальных наворотов сверху - типа индексирование документов (doc, pdf чо там еще бывает), версионинг документов, привязка к oracle workflow и т.п. в смысле "то каким софтом используется" ? - это файловая система, монтирушь к твоей оси и в перед ну или через веб интервейс.
	torvic 13 Aug 2004 12:40 PM
WinFs, Oracle files говорите? web fountain еще забыли. что нового? да нифига нового, как и в oracle files, все эти object/flat fs уже давно жеваны - пережеваны. единственный нормальный ответ был где-то в msdn-овских блогах: сможете завязать свои десктопные приложения на oracle files / web fountain, флаг вам в руки, winfs вам не нужен.
	Chkaloff 13 Aug 2004 2:36 PM
2 Z$: А что были приведены какие-то убедительные факты, говорящие о том, что кто-то что-то подобное уже сделал и внедрил на десктопе?
	Chkaloff 13 Aug 2004 2:43 PM
2 Z$: А если вы про Oracle Files, то это вопервых совсем совсем не то, вовторых решение для серверов, а не для десктопов, и со своей версионностью, процесом утверждения и т.д. это какой-то конкурент Sharepoint'а но никак не WinFS.
	Z$ 13 Aug 2004 4:35 PM
2Chkaloff не тормоззззите - зачем вам документы хранить на десктопе ? вы с ними один работаете ? вы регулярно их бэкапите ? так может тогда и почту на десктоп. решения не бывають для задачи а не для десктопа ;)
	Добрый 13 Aug 2004 6:22 PM
2Chkaloff: ну это, батенька, такие особенности разработки в Microsoft. WinFS не готова, Exchange застрял на полдороги к Юкону, а продукт для работы с документами нужен. Вот и сделали Sharepoint. Отдельно стоящее дерево. Это ж лохи, начитавшись МСДН, ставят СУБД, сверху сервер приложений, а потом уже приложение для работы с документами лепят. В МС все проще. Нет объектной файловой системы? Вставим что есть! Потом напишем отдельно софтину для десктопа. Потом ... Там разберемся!
	RIK 13 Aug 2004 11:41 PM
2 Z$ Единицей хранения данных в WinFS может быть не просто файл, а объект типа "e-mail сообщение", "банковская транзакция" и т.д. Для каждого объекта такого рода определены свойства и методы. Скажем, у e-mail сообщения есть отправитель, адресат, subject и т.д. Основная проблема создания объектной ФС - это стандартизовать эти объекты, т.е., с одной стороны, предусмотреть все случаи жизни и удовлетворить большинство пользователей, а с другой - не переусложнить настолько, что этим нельзя будет пользоваться. Насколько я знаю, MS провела колоссальную работу по согласованию форматов с большим количеством заинтересованных фирм. 2 Добрый А по-подробнее можно - что значит "Exchange застрял на полдороги к Юкону"? >Вот и сделали Sharepoint. Отдельно стоящее дерево. Отдельно от чего? Sharepoint ставится над SQL сервером.
	Chkaloff 14 Aug 2004 12:56 PM
2 Z$: >не тормоззззите - зачем вам документы хранить на десктопе ? Да, храню. У меня notebook и подавляющее число документов я редактирую на нем. >вы с ними один работаете ? с некоторыми один, с некоторыми нет. вы регулярно их бэкапите ? бывает. >так может тогда и почту на десктоп. Дак она у меня итак не десктопе. Я использую Outlook, в котором у меня почта, контакты, встречи. Еще у меня есть PoketPC который с этим всем синхронизируется. На мой взгляд вы путаете, извените за выражение, жопу с пальцем. Там где нужны сервера и хранилища документов у нас и так используются SQL и SharePoint.
	Chkaloff 14 Aug 2004 1:12 PM
2 Добрый: >Это ж лохи, начитавшись МСДН, ставят СУБД, сверху сервер >приложений, а потом уже приложение для работы с документами >лепят. >В МС все проще. Нет объектной файловой системы? Вставим что >есть! Потом напишем отдельно софтину для десктопа. Потом ... >Там разберемся! Sharepoint - это новый взгляд на платформу совместной работы, основанной на Web. Именно платформа. Для нее разрабатываются решения для работы с SAP и т.д. Как хранилище документов, Sharepoint поддерживает все то, что перечислил Z$ (храниение, контроль версий, утверждение документов и т.д.), но кроме этого подерживает мноетсво специфичных функций, таких как различные списки, XML формы InfoPath, связь с ProjectServer для управления проектами и т.д. это и есть платформа для групповой работы. Я могу поискать,например, по названию компании, и шарипоинт просмотрит факсы, которые автоматически индексируются и найдет его. Я могу формировать свое рабочее место из, "кирпичиков" которые мне предоставляет Sharepoint, например могу проиндексировать колонку новостей сайта моего конкурента, и всегда буду в кусре его новостей, и т.д. Еще раз повторюсь, что это платворма, и еслибы вы знали ее архитектуру, то знали бы что она как раз на MS SQL и базируется.
	Skull - sibskullmail.ru 15 Aug 2004 9:06 AM
2domician: "а предпроигрывание и предпросмотр при наведении курсора как оказалось были еще в Проводнике Вин98..." - для каждого по месту (в виде не одного а кучи эскизов)? Скриншот в студию! Равно как и детальное описание как при наведении на mp3-файл он зазвучал в динамике. То же самое для mpeg. Иначе буду считать это пустобрёхством... :)
	Пётр 16 Aug 2004 10:26 AM
2 Chkaloff. Не, индексировать колонку новостей на сайте конкурента это не очень удобно. Нужно в конечном итоге поиск постоянно запускать. Проще поставить на сайте Web-part под названием Web capture. И "натравить" его на сайт конкурента. "Равно как и детальное описание как при наведении на mp3-файл он зазвучал в динамике." Свят-свят. Упаси меня от такой работы. "зачем вам документы хранить на десктопе ?" У меня дома десктоп и на нём хранятся наши семейные документы (ну там проекты ремонта квартиры, фотографии всякие и т.д.) и документы моей жены. Никакого сервера.
	Z$ 16 Aug 2004 10:32 AM
ну тогда возьмите минимальные требования лонгхорна (по железу) и поставте на такой десктоп Oracle collaboration suite за $50 :)
	Chkaloff 16 Aug 2004 11:30 AM
Дорогой Z$, ты похоже не разбираешся в сути. Oracle collaboration за $50 требует СУБД Orcale совсем за другую сумму. И на Notebook ты тоже СУБД Orcale предлагаешь поставить.
	Добрый 16 Aug 2004 12:53 PM
2Chkaloff: > Sharepoint - это новый взгляд на платформу совместной работы, основанной на Web. Именно платформа Да? А я думал, что новый взгляд и новая платформа Microsoft - это Net. Извини, ошибся. Буду знать, что новый взгляд - это хтмл-интерфейс на JavaScript и оригинальный формат базы данных. Вот пример групповой работы. Партнер их Сан-Франциско прислал мне документ. Я его переработал, обсудил с коллегами, они внесли свои изменения. С результатами я пошел к клиенту на переговоры. Все у меня на технологиях Microsoft. Переписка с партнером лежит на сервере Exchange и в папках Outlook. Групповая работа происходила на сервере Sharepoint. Просить у клиента "доступ к интернету на 5 минут" мягко говоря несолидно, поэтому я заранее копирую необходимые документы на ноутбук. В ходе переговоров я создаю новые версии. В итоге один документ размазан по 2-м разным серверным хранилищам MS и десктопу MS. Не сомневаюсь, что несложно написать web parts, которые ищут сразу в 3-х местах. 2Пётр: >"зачем вам документы хранить на десктопе ?" У меня дома десктоп и на нём хранятся наши семейные документы (ну там проекты ремонта квартиры, фотографии всякие и т.д.) и документы моей жены. Никакого сервера. Аналоги WFS выпускались 5-6 лет назад. Вот например, отечтсвенные разработки 1999 года. http://offline.computerra.ru/1999/320/3325/ Только чисто десктопные решения тогда скоро заглохли, так как тогда домашние пользователи в большинстве своем имели слишком мало документов на диске С. Сейчас много цифровых фоток, mp3 и тема снова ожила. так что технологически это несложно, другое дело, что интеллектуальность поиска у гугля повыше, чем у msn
	Z$ 16 Aug 2004 1:48 PM
1. Oracle collaboration еще требует oracle infastructure, iAs и т.п. но это за это не нужно платить, все это стоит $50, просто кроме как в ocs эти части юзать нельзя. 2. а mssql вместе с лонгхорн ты будешь ставить на ноутбук ? если да то и ocs тебе нично не помешает поставить :) это не менее идиотская идея чем пихать 4GB для sql server в десктоп чтоб индексировать пару тысяч mp3.
	Пётр 16 Aug 2004 2:08 PM
2 Добрый. а чекаут документу сделать перед поездкй к клиенту сделать слабо было? а потом обновления туда выложить? Я лично так и делаю.
	Chkaloff 16 Aug 2004 2:25 PM
Z$ >mssql вместе с лонгхорн ты будешь ставить на ноутбук ? WinFS не требует MSSQL. Съели?
	Chkaloff 16 Aug 2004 2:38 PM
2 Добрый: >>Sharepoint - это новый взгляд на платформу совместной работы, >>основанной на Web. Именно платформа >Да? А я думал, что новый взгляд и новая платформа Microsoft - >это Net. NET - это платфома разработки (C#, CLR, IL слышали?), а Sharepoint - платформа для collaboration. Разницу чувтствуете? Или для вас тофлуи на платформе и железнодорожная платформа - это тоже одно и тоже. Я не понимаю, толи вы просто придуриваетесь, толи действительно слышали звон, да не знаете где он. На счет check-out документов Петр уже ответил. >Аналоги WFS выпускались 5-6 лет назад. >Вот например, отечтсвенные разработки 1999 года. >http://offline.computerra.ru/1999/320/3325/ А с чего вы взяли что программы-ищейки аналоги WinFS? MS Access гораздо более аналог Orcale чем программы-ищейки WinFS.
	Z$ 16 Aug 2004 2:48 PM
>WinFS не требует MSSQL. Съели? ну ламер, winfs это и есть mssql yukon.
	Вlack ibm.* 16 Aug 2004 3:01 PM
а есть ли какие нибуттпроректы аля OSS для интеграции CORBA и .NET? и как сейчас обсталтя дела с CORBA.??
	Добрый 16 Aug 2004 3:12 PM
2Chkaloff: >NET - это платфома разработки (C#, CLR, IL слышали?), а Sharepoint - платформа для collaboration. Разницу чувтствуете? Вот-вот! Вы мыслите в правильном направлении :) Осталось дойти до мысли, что приложение (для групповой работы) должно базироваться на стандартной среде исполнения и средствах разработки и базе данных (Net, SQL server &amp; studio). Система, коя базируется на хтмл, жаба скрипте и собственной оригинальной базе данных, а в качестве среды разработки предлагает фронтпейдж, весьма интересна но уж никак не является "новым взглядом"
	Chkaloff 16 Aug 2004 3:40 PM
2 Z$: Сам ты ламер. mssql yukon - это mssql 2005. WinFS - это WinFS. Абсолютно разные продукты. Или вы считаете что для того чтобы пользоваться WinFS придется ставить на все компьютеры SQL 2005? А какую редакцию, если не секрет? А почему она базируется в данный момент на NTFS, ведь базу данных MSSQL можно хоть на RAW партиции держать? Еще какие сказки есть? Или может быть вы, не разобравшись в сути, счиатете что раз в WinFS одним из методов доступа к данным есть T/SQL, и из этого сделали скоропалительные выводы об установке MSSQL 2005? Вообщем смотрите архитектуру WinFS и не болтайте ерундой. http://msdn.microsoft.com/library/en-us/dnwinfs/html/winfs0 3112004-01.gif (форум добавит пробел в ссылку - надо его удалить).
	Z$ 16 Aug 2004 3:56 PM
http://www.microsoft.com/uk/msdn/flash/20040524.htm WinFS - building on NTFS and exploiting the SQL Server "Yukon" engine to allow new ways to find, relate, and act on information (files, contacts, appointments, etc.) regardless of which application created the data. я конечно понимаю что вы манагер, но что такое relational engine и какое отношение он имеет к sql server engine (который не только в mssql'е но и msdn&amp;express server) надо до бы знать чтоб так не позорится. если у вас проблема с англицким почитайте сдесь последний параграф. http://zdnet.ru/?ID=311747
	Добрыйча 16 Aug 2004 4:05 PM
2Z$: Да. Ловко Chkaloff разоблачил ламеров на www.microsoft.com... Маладец адназначна!
	Chkaloff 16 Aug 2004 4:39 PM
2 Добрый: Всетаки прежде чем что-то заявлять, предлагаю вам сначала прочитать по теме разговора хоть что-то. А то ведь в каждом посте показываете свое незнание вопроса. >Осталось дойти до мысли, что приложение (для групповой работы) >должно базироваться на стандартной среде исполнения и >средствах разработки и базе данных (Net, SQL server &amp;amp; > studio). В отличии от первой версии продуктов (котораы назывались SharePoint Team Services и SharePoint Portal Server) Windows SharePoint Services и SharePoint Portal Server 2003 постороены по технологии NET. Assembly Microsoft.SharePoint.dll и одноименный неймспейс. Разумеется, SharePoint базируется на MSSQL. Можно на бесплатной версии MSDE. Веб часть для SPS и WSS написаны на ASP.NET. Разработка для SharePoint ведется с помощью Visual Studio. VS интегрируется шаблон для создания вебчастей. >Система, коя базируется на хтмл, жаба скрипте и собственной >оригинальной базе данных, а в качестве среды разработки >предлагает фронтпейдж HTML и JavaScript есть на 90 с гаком % компьютеров мира. Общепринятые технологии. Ну да MSSQL вполне оригинальная БД. Надо было делать на MySQL? Уж простите, вас не спросили в этом. FrontPage (причем только 2003) это не в качестве среды разработки, а в качестве визуального редактора, чтобы можно было просто работать с дизайном и размещением. Можно и в notepad'e много редактировать. Вообщем, товарищ , RTFM!
	Chkaloff 16 Aug 2004 5:11 PM
2 Z$ Вы маркетинговую лапшу с ушей снимайте иногда. Когда MS выгодно представлять что WinFS - основана на SQL 2005, то она делает это. На ресурсах для разработчиков такие вещи не пишут. http://msdn.microsoft.com/Longhorn/understanding/pillars/Wi nFS/default.aspx http://msdn.microsoft.com/Longhorn/understanding/pillars/Wi nFS/default.aspx?pull=/library/en-us/dnwinfs/html/winfs03112 004.asp Разумеется часть кода там общая, ну и что. Indexing Service, Full-Text Serach, поиск в HTML-HELP используют одни и те же алгоритмы, но это не дает права называть их одними продуктами. Разумеется, физически код будет разный и оптимизированный под задачу. Или вы намекаете, на то, что этот код громоздкий будет? Что вам дает основание так утверждать? Если вы уж так хотите аналогии между этими продуктами проводить, про SQL Server CE напомнить?
	Z$ 16 Aug 2004 5:21 PM
ну конечно не пишут, это коню ясно, ну не знали они что манагер тут начнет "доказательства" искать :) >Что вам дает основание так утверждать? системные требования, которые очень напоминают требования к oracle database enterprise edition ;)
	torvic 16 Aug 2004 5:29 PM
> winfs это и есть mssql yukon openLDAP, sendmail, apache, так это ж ваще получается одно и тоже?
	Z$ 16 Aug 2004 5:47 PM
2torvic: на lingvo.yandex.ru есть словарик, с его помощью вы сможете перевести фразу WinFS - building on NTFS and exploiting the SQL Server "Yukon" engine и не задавать идиотских вопросов.
	Chkaloff 16 Aug 2004 5:55 PM
2 Z$: >>Что вам дает основание так утверждать? >системные требования, которые очень напоминают требования к >oracle database enterprise edition ;) А ссылочку приведете на эти самые системные требования, которые WinFS накладывает (не Aero и не Aero Glass)? А то без этого как-то все безапеляционно получается.
	torvic 16 Aug 2004 6:22 PM
2 Z$ WinFS - building on NTFS and exploiting the SQL Server "Yukon" engine :: "winfs это и есть mssql yukon" так это lingvo так перевел? во тупой ...
	кун4ненн54р45 16 Aug 2004 6:23 PM
2Z$ А вот интересно, раз в составе виндов идет msjetXX.dll, означает ли это, что у всех стоит MS Access? Ведь engine есть!?
	domician 17 Aug 2004 1:48 AM
2 Skull >> Иначе буду считать это пустобрёхством считайте :) то что я сказал это пустобрёхство... ну никак не могла быть такая прогрессивная фича реализована в отсталом Проводнике Win 98/2k, это тока в продвинутом КДЕ сие возможно... а если без шуток, то в ходе дискуссии с одним линуксойдом он мне как раз привел пример предпроигрывания/предпросмотра в КДЕ, как преимущество лин... типа, вон у нас в линуксе чего есть, сделайте так в виндовс... я сначала стал искать сторонние плагины в Эксплореру, а потом всплыла любопытная инфа насчет вин98/2k - оказывается, и штатными средствами можно :) >> для каждого по месту (в виде не одного а кучи эскизов)?Скриншот в студию я лучше просто напишу, как... можно в виде кучи эскизов, можно в виде одного при наведении курсора... сначала включаем реакцию на наведение курсора - в Проводнике меню Сервис - > Свойства папки, закладка Общие в группе Щелчки мышью ставим флажок Открывать одним щелчком, выделять указателем... потом предпросмотр - Сервис -> Свойства папки, закладка Общие, группа Представление папок в виде веб-страниц, ставим флажок Отображать веб-содержимое в папках... (сделано немного по другому - слева в области окна будет картинка, имхо так удобнее чем в тултипе КДЕ, этот тултип мне загораживает кучу имен других файлов) >> Равно как и детальное описание как при наведении на mp3-файл он зазвучал в динамике. То же самое для mpeg Пжалста... включаем предпроигрывание - меню Вид -> Настроить вид папки... запускается Мастер настройки вида папки, Далее, радиокнопка Задать особые параметры вида папки, флажок Выбрать или изменить HTML-шаблон для этой папки, Далее, выбрать шаблон Стандартный, поставить флажок Я хочу изменить этот шаблон, Далее... теперь Мастер откроет в блокноте folder.htt, там надо в двух местах для параметра AutoPlay заменить false на true... сохранить изменения, нажать Готово... все, предпроигрывание аудио + видео включено... это я проверил на W2k, к сожалению по дефолту в XP на закладке Общие нет группы Представление папок в виде веб-страниц, как объясняет сама МС, отключено в целях безопасности... но можно включить через реестр... а вот Мастер настройки вида папки вообще убрали из XP, тем не менее можно вручную создать folder.htt... фича предпросмотра и предпроигрывания вообще-то древняя, впервые в вин98 появилась... теперь вы понимаете, откуда спионерили идею разработчики КДЕ :) кстати, а как в КДЕ включается предпроигрывание видео? хоть в тултипе, хоть где... и желательно не в последнем КДЕ 3.2, а допустим в 3.1.1, чтоб я проверить мог (у меня версия КДЕ такая) еще у меня с этим линуксойдом была дискуссия насчет клипборда... меня пытали, а где у вас буфер активный и многоместный в винде :) я говорю, вот вам 10 утилит на много мест :) а насчет активности - не нашел утилитку сразу, так сам напишу... тоже мне проблема поставить глобальный хук на отпускание левой кнопки мыши при выделении текста, и другой хук на среднюю кнопку для вставки... а вот как быть с киданием через буфер КДЕ (с Клиппером и без него)объектов/файлов разного формата... чтоб не только текст... и не ссылка на файл (тоже текст)... а именно содержимое объекта/файла (картинка, аудио, видео) можно было в буфер копировать (ну и вставить потом в документ Райтера или еще куда)... виндовый буфер это умеет еще со времен вин95... ну не может быть, чтобы буфер в новейшем КДЕ был такой примитивный :) про активный фокус еще речь заходила... А ГДЕ ОН В ВИНДЕ??? :) я говорю, да вот, Tweak UI из повертойза его включает одной галочкой (а другая позволяет выбирать, будет ли окно всплывать поверх всех при наведении мыши)... это через реестр собсно включается, причем можно было делать для старой Win95
	Xe-Xe - billmicrosoft.com 17 Aug 2004 6:04 AM
Ну и разоогнались же тут вы товарыщи... И места не жалко ?? --- ЗЫ: очень Билли не любили, и за ето силллльно били.
	fi 17 Aug 2004 7:21 AM
то domician "про активный фокус" за mouse на Winxxx, пробывал я это - одна пародия. A про mouse copy+paste одним движением и шелчком можно по подробней? А то иногда мне приходится с Winxxx встречаться - сильно напригает убогий интерфейс в стантартной винде.
	glassy 17 Aug 2004 7:23 AM
> Tweak UI из повертойза его включает одной галочкой (а другая > позволяет выбирать, будет ли окно всплывать поверх всех при > наведении мыши)... это через реестр собсно включается, причем можно > было делать для старой Win95 не скажу про остальное, но конкретно эта фича не работает. Попробуй включи и обрати внимание на поведение "выпадающих списков".
	Алексей 17 Aug 2004 4:14 PM
к идскуссии domician и Skull KDE -- могила Linux ибо оно является подражанием Windows. Если сравнивать ворованную винду и бесплатное KDE, то первое безусловно выигрывает по красоте и удобству. Но красота нужна только тем, кто весь день пасьянсы раскладывает, а удобство тем, кто не умеет с компом обрадаться (в частности, предпросмотр нужен только тем, кто файлы называет doc1.doc, doc2.doc...). KDE может радовать только того, кто man twm ни разу не читал. Для них скажу, что twm постоянно развивается, не содержит ничего лишнего и при этом поддерживает огромное количество очень удобных функций. Например у меня каждое окошко имеет кнопочку при нажатии на которую меняется его поведение: при получении фокуса всплывать/не_всплывать. Попробуйте в KDE сделать чтобы только одно окно жило по опредлённым правилам? KDE с упорством достойным лучшего применения повторяет все за Билом, открывая дорогу разработчикам дистрибутивов идти той же дорогой. Во времена ядра 2.2 KDE было чем-то отдельным. Во времена 2.4 многие дистрибутивы без KDE уже не ставились, даже если от него отказаться. Теперь перейти на 2.6 без KDE невозможно. Но мне-то зачем KDE? Теже винды.
	fi 18 Aug 2004 8:04 AM
то Алексей KDE - прекрасная оболочка, умеет очень многое.
	Алексей 18 Aug 2004 11:16 AM
сравните: было много прекрасных оболочек, стало одна прекрасная КДЕ (о прекрасности которой говорят те, кто сравнивает её с виндами, а не с тем многообразием, которое было) и согласитесь, что прекрсность состоит в том, что ничего не надо надо настраивать, а умеет КДЕ _почти_ всё, что умеет винда. пример: когда втыкаешь флэш, КДЕ приям как винды говорит, что новый диск появился и конкурер запускает, но в винде при этом ещё и иконка появляется, чтобы эту флэш отмонтировать, а в КДЕ ничего такого не происходит, может быть это и можно настроить только где?; тотже twm настраивается в одном файле и не надо прилагать никаких усилий, чтобы добавить в меню команы "примонтировать флэш"/"отмонтировать флэш". про локализацию просто молчу. любому wm достаточно LANG=ru_RU.koi8-r, но только не КДЕ. SuSE 9.1 я так и не смог поставить так, чтобы в КДЕ всё порусски работало. === У человека всегда есть выбор: либо он всецело повеливает малым, либо наслаждается необозримым, не имея никакой власти над ним. тот же twm мал, но полностью управляем, КДЕ прекрасно, но найти концы в нём невозможно. так вот, люди первой категрии отказываются от винды принципиально и КДЕ им не нужно, люди второй категории не принципиально отказываются от винды. навязывая всем КДЕ линукс теряет принципиальных сторонников, становясь просто новой виндой (иконки другие, идея таже), и уходит с пути unix.
	Z$ 18 Aug 2004 2:14 PM
KDE всего лишь одна из сотен оболочек, просто самая раскрученая, она удобна для тех кто слазят с виндов, посидят какое-то время в KDE и через какое-то время некоторые из них дорастут до более подходяще для их работы WM ... но это будут 10% и слава богу.
	Wintermute - devnul.ru 18 Aug 2004 3:23 PM
2 Алексей: "man twm" Н-да, я, конечно, знал, что среди шлюниксоидов много извращенцев, но ТАКОГО я себе представить не мог... В общем, twm - это настоящая машина времени. Из 2004 в 1984. Amiga. Если ЭТО - прогресс, я хочу в пещеру! А вообще, все X wm убоги. Я понимаю, когда интерфейс винды ругают маковцы. Но юниксоиды...
	Michael Shigorin - mikeosdn.org.ua 18 Aug 2004 3:24 PM
тьху. Одни обсуждают vaporware с умной миной на лице, как будто есть что обсуждать; другие уперлись в вопросы вкусов... А можно я буду пользовать свой реально существующий WindowMaker, который мне не надо пилить как twm (потому что работает и на 21" исхитряться с всплытием просто незачем) и который взлетает за секунду, на своей конкретно ALT Linux-based системе, для решения своих бренных задач, погугливая порой? А не впаривать кому-то, что "все на twm!!", или "KDE -- один мегарулез!!", или вообще (стыдно подумать!) спекулировать тем, что кому-то под маркой причудилось про фичи Linux 3.11. А? Можно? :-)
	domician 19 Aug 2004 12:06 AM
2 fi что вам не понравилось в реализации активного фокуса в виндовс? про автокопирование мышью что поподробнее? :) я утилитку счас пишу, которая это делает... сразу не нашел в сети, а долго искать не люблю - проще самому сделать 2 glassy включил и посмотрел на поведение выпадающих списков... они ведут себя так же как и без Active Focus... вы лучше пример приведите конкретный, чтоб я мог проверить, что где не так
	domician 19 Aug 2004 12:07 AM
2 Алексей знаете, если уж Linux что то и светит на десктопе, то только благодаря КДЕ... нравится он вам или нет :)
	Алексей 19 Aug 2004 12:57 PM
Wintermute ещё одни человек, не читавший man twm. Что вы мождите сказать кроме "Н-да" и "А вообще, все X wm убоги." по этому вопросу? Для тех, кто не понял, я привоже здесь в пример twm, как крайнюю альтернативу KDE. Я не говорю, что это единственый wm :-) Просто возможностей у него не меньше, чем в КДЕ, а настраивается проще. Нестравнимо проще! К тем, кто тут не меня гавкает, я привёл конкретные примеры удобства и неудоства. Жду от вас опровержений и своих примеров, а перетяфкиваться смысла не вижу.
	fi 19 Aug 2004 1:50 PM
то domician > что вам не понравилось в реализации активного фокуса в виндовс? сильно тормозит вся система, такое ощущение что сделано это путем цикла while(1) ;-)), плюс глюки со всякими меню, причем иногда не повторимые. >про автокопирование мышью что поподробнее? А что про нее писать - работает и все, со своим буфером обмена.
	glassy 19 Aug 2004 2:06 PM
2domician: (Какой-то я прямо добрый сегодня...) Комбобокс. Нажимаю на стрелку. Выпадает список -- это нормально. Тяну курсор мышки к этому списку. Опть!! Он исчезает! Окно диалога опять поверх всех окон. 2Wintermute: а разве сама идея иконок на рабочем столе себя НЕ СКОМПРОМЕТИРОВАЛА? Это мне наверное во сне приснилось -- новейшие виндовз с одной лишь корзиной.
	Wintermute - devnul.ru 19 Aug 2004 4:48 PM
2 Алексей: "тут не меня гавкает" "С тобой не гавкает, а разговаривает оперуполномоченный Жеглов!" (С) братья Вайнеры "только одно окно жило по опредлённым правилам" Читаем ИБМовскую доку по CUA. Окна, живущие по своим правилам, были актуальны в 1984 году. Реально эе каждое окно должно, _обязано_ жить по раз и навсегда заведенным правилам. Это сильно сокращает learning curve юзера.
	Wintermute - devnul.ru 19 Aug 2004 4:51 PM
2 glassy: "2Wintermute: а разве сама идея иконок на рабочем столе себя НЕ СКОМПРОМЕТИРОВАЛА?" С чего бы? Тебе прислать скриншот моего десктопа? Хошь рабочего, хошь домашнего? "Это мне наверное во сне приснилось -- новейшие виндовз с одной лишь корзиной." Точно, приснилось. Я вчера как раз игрался с XP на новом Dell, так там этих иконок сразу после установки больше, чем в 95 по умолчанию. Ну, я ее, разумеется, сразу же на старый, 2000, лад переделал, меня эти "телепузики" раздражают.
	Алексей 19 Aug 2004 6:36 PM
2Wintermute "Реально эе каждое окно должно, _обязано_ жить по раз и навсегда заведенным правилам." В таком случае может быть все окна _обязано_ должны быть одинаково оформлены и иметь одинаковые элементы управления? Расскажите это разработчикам XMMS или KNotes (если уж про K говорить). "Life biger" (c) REM А вопрос в том, что почему разработчики _не_обязаны_ деражться стандартов, а (повидимому) _обязан_ пользовать КДЕ и навязанными ею "удобствами". А иконки на рабочем столе действитльно удобны только когда запущено не более одного приложения и оно является пасьянсом или калькулятором (не требует раскрытия во весь экран).
	domician 20 Aug 2004 1:24 AM
2 fi > сильно тормозит вся система при включении активного фокуса? :) да чему там тормозить-то... в рестре один-два бита выставляются (в HKCU\Control Panel\Desktop\UserPreferencesMask), и система начинает делать окна активными при наведении курсора - совсем не ресурсоемкая операция... у меня никаких тормозов нет > плюс глюки со всякими меню, причем иногда не повторимые. причем тут меню и какие с ним глюки и вы упоминали про удаление исполняемых файлов в unix-like - что можно удалять когда они запущены... это те которые проецируются, или по-старому загружаются? не совсем понятно, как можно без последствий удалить спроецированный файл, да чтобы он после удаления продолжал выполняться... это копировать что ли все в память при удалении? проецирование так сказать превращается в обычную загрузку? 2 glassy > Комбобокс. Нажимаю на стрелку. Выпадает список -- это нормально. Тяну курсор мышки к этому списку. Опть!! Он исчезает! Окно диалога опять поверх всех окон. Курсор у вас исчезает? :) у меня нет - я ведь сказал что с Active Focus, что без него поведение списков одинаково... а чем вы включали Active Focus и на какой винде... я проверял Tweak UI на WinXP, Win2003 да, вопрос есть, будьте добры подскажите, как в линуксе делается асинхронное чтение и запись файлов? фича весьма привлекательная, и конечно должна быть реализована в современной ОС, но злые языки мне говорят, что этого в линуксе нету :) подчеркиваю, для _файлов_ asynchronous I/O... и расскажите плз как вы через буфер в Linux кидаете картинки, музыку, видео... ведь не может такого быть, чтоб в 2004 г. только текст в линуксе можно было копипастить? :) ведь даже старая вин95 поддерживала кидание объектов через буфер...
	domician 20 Aug 2004 1:24 AM
2 Алексей насчет конкретных примеров удобства и неудоства :) "каждое окошко имеет кнопочку при нажатии на которую меняется его поведение: при получении фокуса всплывать/не_всплывать. Попробуйте в KDE сделать чтобы только одно окно жило по опредлённым правилам?" - в КДЕ можно каждому окну свою тему назначить, вообще-то... можно и в винде сделать определенные правила для каждого окна - например, любое окно можно сделать поверх всех, задать прозрачность (разной степени), свернуть в систем трей или в заголовок, задать координаты и размер окна при появлении... да много чего можно задать не для всех окон, а выборочно (собсно, чисто технически это делается через перехват RegisterClassEx, CreateWindow и оконной процедуры)... вопрос только в том, кому это надо... > Просто возможностей у него не меньше, чем в КДЕ, а настраивается проще. ну это вы загнули :) чтобы маленький twm имел столько же фич как огромный КДЕ... 2 Wintermute > Окна, живущие по своим правилам, были актуальны в 1984 году. Реально эе каждое окно должно, _обязано_ жить по раз и навсегда заведенным правилам. Это сильно сокращает learning curve юзера. это да, конечно... но все-таки для каждого окна одни и те же правила раз и навсегда - скучно как-то :) для всех окон свои правила - тоже не катит, юзер-интерфейс для сумасшедшего дома :) истина как всегда где-то посредине... к примеру, у меня пара полупрозрачных окон иногда висит сбоку поверх всех (а иногда нет), у винампа и AverTV свое оформление, остальные более менее одинаковы... кстати, активный фокус для меня нисколько не актуален, окна почти всегда на весь экран, переключаюсь между ними через taskbar или alt+tab... ну нету у меня окон, занимающих часть экрана, чтоб через них мышкой водить, и фокус за ней перескакивал :) имхо, неудобная фича этот активный фокус... я как только его попробовал (есть ли он вообще в винде), так сразу и вырубил... так же поступил с предпроигрыванием и предпросмотром... рюшечки все это, а вот что через буфер КДЕ нельзя кидать объекты, кроме текста - это меня неприятно поразило... это уже не рюшечки, это для работы я часто использую
	plug 20 Aug 2004 10:19 AM
2 domician: >>и вы упоминали про удаление исполняемых файлов в unix-like - что можно удалять когда они запущены... это те которые проецируются, или по-старому загружаются? Вы будете смеяться, но это делается очень просто. При удалении файл "вычеркивается" из каталогов и вcяких directory lookup cache в самом ядре, а вот сами данные на диске (и структура, которая описывает их размещение) освобождаются только после того, как завершится последний процесс, их использующий. То же самое относится и к so-шкам (юниксовым аналогам dll'ек). Ничего хитрого. Понятно, что при таком удаленнии свободное пространнство на диске не увеличивается (до завершения "прихватившего" процесса), но зато дает существенные удобства при перемещении в другое место или даже замене исполняемых файликов. ( Если файл удалить, а потом туда же положить новую версию, но с тем же именем, то новые процессы будут использовать уже ее, а старый пусть доработает себе до конца или ближайшей перезагрузки. ) >> да, вопрос есть, будьте добры подскажите, как в линуксе делается асинхронное чтение и запись файлов? фича весьма привлекательная, и конечно должна быть реализована в современной ОС, но злые языки мне говорят, что этого в линуксе нету :) Исли вы о posix'ном AIO, то ... у меня линукса в обозримом окруженнии нету, но недолгий поиск в сети говрит, что - "есть начиная с 2.5". Только вот что такого привлекательного в AIO именно для файлов (не сокетов или пайпов) - не совсем понятно. Разве что на чтении файлов, которых еще нет в файлов кэше, можно какие-то проценты выиграть. :)
	Wintermute - devnul.ru 20 Aug 2004 10:56 AM
2 Алексей: "В таком случае может быть все окна _обязано_ должны быть одинаково оформлены и иметь одинаковые элементы управления? Расскажите это разработчикам XMMS или KNotes (если уж про K говорить). "Life biger" (c) REM" CUA - это стандарт. CUA придерживаются IBM (OS/2), Microsoft (Windows), Apple (MacOS) и даже Be (BeOS). Да, я согласен, что UI от MS отличается от UI от IBM, да, я согласен, что UI guidelines всех перечисленных фирм разные, но все они а) похожи друг на друга (чегщ-то там-C работает во всех этих осях); б) UI внутри этих ОС работают по одинаковым принципам (меню и кнопку OK юзер найдет в каждой оси в привычном месте). Я также знаю, что есть печальные _исключения_ из правил (WMP от MS) и не в восторге от них, это перебор. Но когда _каждое_ окно является исключением, это уже не перебор. "А вопрос в том, что почему разработчики _не_обязаны_ деражться стандартов, а (повидимому) _обязан_ пользовать КДЕ и навязанными ею "удобствами"" Это проблемы пользоватлей KDE, меня на прамую не касаются. "А иконки на рабочем столе действитльно удобны только когда запущено не более одного приложения и оно является пасьянсом или калькулятором (не требует раскрытия во весь экран)" Не надо по себе судить, хорошо? В Windows есть масса способов добраться до иконок на десктопе, даже не минимизируя открытые окна.
	Wintermute - devnul.ru 20 Aug 2004 11:01 AM
2 domician: "перехват RegisterClassEx, CreateWindow и оконной процедуры)" Вообще-то, перехват первых двух функций вообще нужен крайне редко. Оконную процедуру перехватывать надо для изменения поведения "чужого" окна (из user32.dll или comctl32.dll, к примеру). Для "своих" окон достаточно просто зарегистрировать калссы с нужными свойствами и создать окна. В экстремальных случаях можно "на лету" уничтожать и воссоздавать окна по месту, уже с новыми свойствами. Так сделано в VCL. Основная сложность с "фигуристыми" окнами - это их нарисовать. Ну, и их тотальная нестандартность.
	Wintermute - devnul.ru 20 Aug 2004 11:05 AM
2 plug: "Вы будете смеяться, но это делается очень просто. При удалении файл "вычеркивается" из каталогов и вcяких directory lookup cache в самом ядре, а вот сами данные на диске (и структура, которая описывает их размещение) освобождаются только после того, как завершится последний процесс, их использующий. То же самое относится и к so-шкам (юниксовым аналогам dll'ек). Ничего хитрого" Такое же механизм существует в NT с самой первой версии. А вот любопытно, "на ходу", когда программа/модуль исполняется, исполняемый файл можно подменять? В винде "стандартно" - нельзя, если чуть-чуть руки приложить, то можно, в .Net - можно, фишка встроена в загрузчик.
	VicTor 20 Aug 2004 11:39 AM
2 domician: >> сильно тормозит вся система > > при включении активного фокуса? :) да чему там тормозить-то... в рестре один-два бита выставляются (в HKCU\Control Panel\Desktop\UserPreferencesMask), и система начинает делать окна активными при наведении курсора - совсем не ресурсоемкая операция... у меня никаких тормозов нет Ну вы же должны понимать, что там внутри происходит достаточно трудоёмкий процесс - при каждом изменении позиции курсора система обязана получить HWND окна в новой позиции курсора, проверить активность этого окна и активировать его, если надо. Окно всплывает, получает фокус, а предыдущее активное окно получает уведомление о смене фокуса. А всё это делается через очереди сообщений... И каждый раз там проходит вовсе не одно сообщение... А если окна при потере фокуса закрываются (а такими свойствами, как вам известно, обладают выпадающие меню и списки), то эти окошки могут закрыться пока тащишь к ним курсор через другие окна (пример от glassy). А если активируемое таким способом окошко перекрывает окно, которое обладает свойством висеть поверх всех других окон (Task Manager, например), то можно получить весьма забавные эффекты... А какой поток сообщений в этом случае идёт через очереди... Так что тормоз страшный - по определению. Хотя 3GHz могут помочь это не заметить :)
	plug 20 Aug 2004 1:17 PM
2 Wintermute >>Такое же механизм существует в NT с самой первой версии. А чего ж она им не пользуется? Или это опять надо какое-то вошебное слово в реестр прописать?
	Алексей 20 Aug 2004 3:27 PM
2Wintermute: > Но когда _каждое_ окно является исключением, это уже не перебор. Я же не говорю, что _каждое_ :-) Я говорю, что изменть повдение окна в twm можно просто нажатием на кнопочку в шапке. Это бывает очень полезно. Например запустил я в xterm top щелкнул на эту кнопочку и окошко висит поверх всех или выскакивает наверх при наведении мыши. А кнопочка такая делается одной строчкой после прочтения небольшой маны. Может быть такое можно и в КДЕ сделать или в Windows, но я даже не занею где про это читать. Вот в чём минус КДЕ -- в неуправляемости, таящейся за кажищемся удобством. > Это проблемы пользоватлей KDE, меня на прамую не касаются. Вот и я стараюсь не пользваться КДЕ. Даже на машних, где я не хозяин выручает просто `xinit -- :1` а дальше запускай что хочешь. Не очень понял, зачем было защищать КДЕ, если вы её не используете, как я понял? ;-) > В Windows есть масса способов добраться до иконок А зачем их тогда хранить на рабочем столе? ;-))) Не проще ли хранить их только там, где до них можно добраться? :-) Вы хранически защищаете то, что не используете :-)
	glassy 21 Aug 2004 2:40 AM
2domician: про кидание объектов через буфер обмена -- разве идея DDE себя не скомпрометировала?? AS расскажет, сколько геморроя получил лично Билл Гейтс с таких объектов.
	Прохожий 21 Aug 2004 8:57 AM
2 Алексей А причем здесь путь Unix и путь Windows до графических оболочек? Если у Windows удобный интерфейс, то почему бы его не распространить на Unix? Счас вон новое направление возникло: даешь Linux на рабочие станции. Если графический интерфейс не будет максимально похож на Windows, к которому привыкло большинство, то о каком переходе с Windows на Linux может идти речь? Это ж скольким людям придется переучиваться, возможно, платить за это деньги и, спрашивается, зачем?
	Прохожий 21 Aug 2004 9:19 AM
2 glassy Так можно ли, всё-таки, в Линуксе копировать кроме текста что-нить еще через буфер обмена? Мне вот, например, бывает иногда очень удобно картинки копировать из одной программы в другую.
	Алексей 21 Aug 2004 2:09 PM
2Прохожий: "А причем здесь путь Unix и путь Windows до графических оболочек?" У всего, что движется, есть путь. Не так ли? "Если у Windows удобный интерфейс, то почему бы его не распространить на Unix?" 1) А если не удобный? 2) И зачем делать второй Windows? Уже есть cygwin, поставил его и готово.
	кун4ненн54р45 21 Aug 2004 3:32 PM
2VicTor А всё это делается через очереди сообщений... Пральна, я вот мышей ваще не вожу - тока кнопки нажимаю. От нее в очереди сообщений таааакоооее начинается !.. Правда, тормозов от этого мне лично не видно, но все равно - очередь сообщений жалко.
	domician 21 Aug 2004 6:50 PM
2 plug >> недолгий поиск в сети говрит, что - "есть начиная с 2.5". а вы поинтересовалиcь, _что_ из асихронного I/O есть в 2.5? :) или скажем в ядре РХЕЛ 3? :) точно речь идет про асинхронное чтение/запись _файлов_ ? >> Только вот что такого привлекательного в AIO именно для файлов (не сокетов или пайпов) - не совсем понятно. в линуксе этого нет - значит, сие непривлекательно? :) >> Разве что на чтении файлов, которых еще нет в файлов кэше, можно какие-то проценты выиграть не смешивайте файловый кеш с асинхронным I/O :) кстати, Диспетчер кэша в NT сам пользуется асинхронным опережающим чтением... а вообще асинхронный ввод-вывод вещь хорошая - не дожидаться окончания записи в любой файл, а сразу продолжать работу (когда ОС закончит запись, она уведомит приложение)... асинхронное чтение, имхо, менее актуально, программе труднее найти чем заниматься пока файл асинхронно считывается (тут ведь данные нужны для продолжения работы) - но тоже неплохо (пока большой файл грузится, можно заранее окно создать, где он будет отображаться, инициализировать структуры, связанные с этим файлом и т.д.)
	domician 21 Aug 2004 6:50 PM
2 VicTor >> Ну вы же должны понимать, что там внутри происходит достаточно трудоёмкий процесс трудоемкость при смене активного фокуса в винде :) хорошо, я бы хотел послушать как это делается в КДЕ/linux... >> при каждом изменении позиции курсора система обязана получить HWND окна в новой позиции курсора, проверить активность этого окна и активировать его, если надо. Окно всплывает, получает фокус, а предыдущее активное окно получает уведомление о смене фокуса. а чем отличается-то этот процесс в КДЕ? или в twm ? :)и почему вы решили что трудоемкость высокая? :) на все это надо несколько сотен команд - выполнится за 0,001 сек... вот мне линуксойды в пример приводили предпроигрывание... вы знаете какая там трудоемкость, в отличие от активного фокуса? :) при наведении курсора загрузка процессора скачет на 15-80%... и линуксойдов трудоемкость не смущает :) они ведь в Системный монитор не смотрели, как я... кстати, гляньте в Диспетчер задач, когда в винде активный фокус включен - на сколько загрузка процессора растет при движении курсора между окнами? :) >> А всё это делается через очереди сообщений вы про асинхронные сообщения ничего не слышали? :) кои посылаются напрямую оконной процедуре, минуя очередь сообщений... скажу больше, в принципе любое сообщение WM_*** может быть синхронным или асинхронным, это как решит система или другое приложение (т.е. вызывается PostMessage или SendMessage) >> А если окна при потере фокуса закрываются эти окошки могут закрыться пока тащишь к ним курсор через другие окна (пример от glassy). пример от гласси у меня не работает :) а что, в КДЕ выпадающие списки не закрываются, пока "тащищь к ним курсор через другие окна"? >> А если активируемое таким способом окошко перекрывает окно, которое обладает свойством висеть поверх всех других окон (Task Manager, например), то можно получить весьма забавные эффекты. какие эффекты? поконкретнее... я проверю... и вы уверены, что такие эффекты, если они есть, происходят только в винде? а в линукс - в аналогичной ситуации - никаких эффектов нет? мы вообще обсуждаем недостатки активного фокуса как такового, или его реализации в виндовс? :) >> А какой поток сообщений в этом случае идёт через очереди. через очереди вообще-то ВСЕГДА идет интенсивный поток сообщений... вы утверждаете, что его интенсивность при авт. смене фокуса возрастает раза в два? :) а доказательства можно? :) >> Так что тормоз страшный - по определению. Хотя 3GHz могут помочь это не заметить да ну что вы... я проверял на Селерон 633, 900 - никаких тормозов... собсно, мне бы хотелось послушать насчет действий системы при смене фокуса в KDE :) для сравнения трудоемкости :) а вот где "тормоза страшные" - это для предпроигрывания :) еще при предпросмотре загрузка проца подскакивает... а ведь обе эти фичи мне совсем не нужны, тогда как мои оппоненты их пользуют в КДЕ в полный рост и приводят в пример :)
	domician 21 Aug 2004 6:50 PM
2 Wintermute >> Вообще-то, перехват первых двух функций вообще нужен крайне редко глобальные перехватчики (вроде Actual Windows Manager), изменяющие поведение любого окна как раз должны отслеживать вызовы RegisterClassEx и CreateWindow... а как иначе узнать адрес чужой WndProc, стиль, меню, фон и т.д... и координаты другие надо подставлять (если надо, чтоб конкретное окно появлялось в определенном месте экрана, и имело определенный размер) >> Для "своих" окон достаточно просто зарегистрировать калссы с нужными свойствами и создать окна. ессесно :) но я-то говорил про возможность изменить поведение _любого_ окна, а значит подразумевается программа с глобальными хуками >> В экстремальных случаях можно "на лету" уничтожать и воссоздавать окна по месту, уже с новыми свойствами. Так сделано в VCL. ну, это позволяет стандартный Win32 API, которым и пользуется VCL >> Такое же механизм существует в NT с самой первой версии. не знал. расскажите плз, как NT позволяет горячее удаление спроецированных в память файлов >> А вот любопытно, "на ходу", когда программа/модуль исполняется, исполняемый файл можно подменять? можно. вот сейчас вспомнил, эту тему я с no-dashi на ЛОРе обсуждал :) там пример был, про горячий апдейт сервиса. механизм замены в принципе почти такой же, как при горячем удалении 2 glassy >> про кидание объектов через буфер обмена -- разве идея DDE себя не скомпрометировала?? DDE конечно устарел, но почему вы его к буферу привязываете? :) концепция кидания объектами вообще - совсем не устарела и активнейшим образом используется всеми приложениями, в т.ч. и через буфер :) мда... как выясняется, что в линуксе чего нет - так линуксойды это упорно называют правильным (или говорят, нафиг не надо :))... не работает инверсия приоритетов - правильно... нет асинхронного I/O для файлов - правильно :) нечто подобное насчет буфера я и ожидал :) "ну это просто в духе glassy" (c) PTO :) не можете ничего кроме текста кидать через буфер, и объявляете именно такую реализацию буфера правильной :)
	VicTor 22 Aug 2004 4:33 PM
2 domician: >> А всё это делается через очереди сообщений > > вы про асинхронные сообщения ничего не слышали? :) кои посылаются напрямую оконной процедуре, минуя очередь сообщений... скажу больше, в принципе любое сообщение WM_*** может быть синхронным или асинхронным, это как решит система или другое приложение (т.е. вызывается PostMessage или SendMessage) Ну вы же знаете, что это ничего не меняет. Раз уж вы демонстрируете такое прекрасное знание различий методов SEND и POST, то наверняка знаете также, что очень часто стандартный обработчик сообщений, обрабатывая какое-либо сообщение, генерирует еще несколько сообщений. Некоторые из них передаются методом SEND, другие - POST. Например, при смене фокуса генерируется последовательность сообщений, в которой WM_ACTIVATE может передаваться как методом POST, так и методом SEND, а WM_PAINT - всегда методом POST. > мы вообще обсуждаем недостатки активного фокуса как такового, или его реализации в виндовс? Я предпочитаю обсуждать "недостатки активного фокуса как такового И его реализации в виндовс". Поскольку Линукс мне, мягко говоря, параллелен :) > а вот где "тормоза страшные" - это для предпроигрывания :) еще при предпросмотре Ну тут вообще впечатления незабываемые :) Поиск всех изображений (было ~8000 файлов), да ещё с предпросмотром... Не спасают ни 2.8GHz проц, ни 2Gb мозгов...
	glassy 22 Aug 2004 9:07 PM
2domician: В линуксе для текста == один буфер, для картинок -- другой, для просто значений цветов -- третий, для файлов и папок -- четвертый. Что ты привязался к этим будферам обмена? Их наваять -- как два пальца об асфальт. Хочешь -- через юникс сокеты, хочешь, через TCP/IP, хочешь, через иксовые атомы. 2VicTor: > Ну тут вообще впечатления незабываемые :) Поиск всех > изображений (было ~8000 файлов), да ещё с предпросмотром... Не > спасают ни 2.8GHz проц, ни 2Gb мозгов... А ты не пробовал пользоваться "правильными" утилитами? :)
	plug 23 Aug 2004 11:05 AM
2 domician: >>а вы поинтересовалиcь, _что_ из асихронного I/O есть в 2.5? :) или скажем в ядре РХЕЛ 3? :) точно речь идет про асинхронное чтение/запись _файлов_ ? Гхм. Вы хотите, чтобы я для вас выполнил поиск и должил результаты? А вы согласны мне оплатить эту работу? :) Ладно, к счастью подвернулась подходящая ссылка http://lse.sourceforge.net/io/aio.html Как выясняется оно _только для файлов_ и есть. :) Но не торопитесь критиковать, это только один из механизмов и одна из имплементаций. >>в линуксе этого нет - значит, сие непривлекательно? :) А что это вы отвечаете вопросом на вопрос? :) Тем более не выяснив - действительно ли "в линуксе этого нет". >>а вообще асинхронный ввод-вывод вещь хорошая - не дожидаться окончания записи в любой файл, а сразу продолжать работу (когда ОС закончит запись, она уведомит приложение)... Вот я это и спрашиваю. (И не ищите здесь под"бки, мне самому просто любопытно.) Дело в том, что обычный снхронный write для файла пишет только в кэш и тут же завершается. Если он будет возвращаться до копирования, то что здесь можно сэкономить? "Линейное" переписывание из буфера в буфер съедает мало времени (больше потеряете на переключении контекстов). К тому же, чтобы юзерский процесс мог хоть что-нибудь в это время сделать, надо чтобы количество CPU было не просто >1, а сравнимо с количеством активных процессов, поскольку системные приоритеты все равно выше и есть большая вероятность, что ядерная процедура (которая будет копировать буферы) отберет процессор именно у вашего приложения. Правда кроме самого копирования может понадобится время для "аллокации" нужного буфера в кэше. Но это уже зависит от нескольких условий. Если же вам нужно дождаться именно записи на диск, то ... это уже немного другая задача. Кроме того, вы уж излагайте сразу задачу (вот типа "не дожидаться окончания записи в любой файл, а сразу продолжать работу"). Кроме posix AIO (который, как высняется, в Линуксе реализован не полностью, но именно для тех случев, где он действительно что-то дает) есть еще readiness signals, которые в связке с non-blocking IO дают тоже самое. (Вот искать - насколько они реализованы в линухе, мне лень. Если вам интерсно - сами найдете.) Вот загляните в этот обзорчик http://www.kegel.com/c10k.html . Там правда больший упор сделан на сокеты. Но как обзор механизмов сойдет. И кстати обратите внимание, что имплементаций posix AIO для линуха там упоминается три штуки. Если вам действительно нужно для работы (а не иллюстрации к глупостям типа "если в линуксе нет, то этого никому не надо"), то выбрать есть из чего.
	Tolik 23 Aug 2004 11:56 AM
О, опять крупный программист glassy, не знающий, через какой механизм работает критикуемый им буфер обмена Windows предлагает каждый раз, когда я хочу что-то скопировать сначала создать свой буфер обмена на базе сокетов (потом еще не забыть для его работы порт на файрволле открыть ;-)) Да неохота мне буферы писать, я копировать хочу
	Wintermute - devnul.ru 23 Aug 2004 1:36 PM
2 plug:"А чего ж она им не пользуется?" Дык она пользуется.
	Wintermute - devnul.ru 23 Aug 2004 1:49 PM
2Алексей: "Я же не говорю, что _каждое_ :-) Я говорю, что изменть повдение окна в twm можно просто нажатием на кнопочку в шапке" И изменится вид/поведение всех окон или только этого окна? Если всех, то это всего лишь другой способ вызова настроек тем/десктопа. Если только этого конкретного - то это противоречит всем стандартам. Окна/контролы, выполняющие похожие функции, должны быть похожими, а то и вообще выглядеть одинаково. "Не очень понял, зачем было защищать КДЕ, если вы её не используете, как я понял" Я не защищаю, KDE - это недоразумение. Но это лучшая оконна оболочка (кроме, возможно, гнома) под юникс. "А зачем их тогда хранить на рабочем столе" А почему бы не хранить их на столе? Если это удобно? И если есть другие способы до них добраться? И если хранение иконок не противоречит стандартам?
	Wintermute - devnul.ru 23 Aug 2004 1:52 PM
2 glassy: "про кидание объектов через буфер обмена -- разве идея DDE себя не скомпрометировала??" А при чем здесь DDE? "AS расскажет, сколько геморроя получил лично Билл Гейтс с таких объектов" Вот блин... Я только час назд использовал такие объекты, а от них, оказывается, геморрой... Ты вот лучше скажи мне - а как в люликсе картинки из одно программы в другую вставляются? ASCII art? А музыка? Ноты?
	plug 23 Aug 2004 1:59 PM
2 Wintermute: >>Дык она пользуется. Вообще-то этого даже domician, которого трудно заподозрить в полном незнании MS'овских операционок, не заметил. А у меня тогда простой дилетантский вопрос: Если NT может удалить файл исполняемого в данный момент приложения не нарушая его работу, то почему это запрещено в юзерском интерфейсе? Например, ни explorer, ни cmd не дают удалить файл <чего-нибудь>.exe, если он в данный момент запущен. Пoчему так? Или - для чего этот запрет? (Да, на всякий случай... Проверил на том, что было под рукой - Win2000 Server и WinXP Pro. Обе вроде как NT-based.)
	Wintermute - devnul.ru 23 Aug 2004 2:02 PM
2 domician: "должны отслеживать вызовы RegisterClassEx и CreateWindow... а как иначе узнать адрес чужой WndProc, стиль, меню, фон и т.д... и координаты другие надо подставлять (если надо, чтоб конкретное окно появлялось в определенном месте экрана, и имело определенный размер)" Хм, SetWindowsHook, возможно? И не надо таблицы импорта править и всякой другой магией заниматься. AFAIK, печально знаменитя ctl3d.dll как раз это и делала. "ессесно :) но я-то говорил про возможность изменить поведение _любого_ окна, а значит подразумевается программа с глобальными хуками" Видимо, мы говорим одни слова, но подразумеваем разные вещи. IMHO, хук и перехват - разные вещи. IMHO, перехват - это подмена точки входа соотвествующей функции. А хук - это легальный, но ограниченный спсоб сделать тоже самое. "не знал. расскажите плз, как NT позволяет горячее удаление спроецированных в память файлов" Не горячее, а отложенное. DeleteFileEx с флагом отложенного удаления. Название флага - уволь, не помню, надо в SDK смотерть, а его под рукой нет :( Что касается спроецированных на память файлов - так они создаются/открываются с флагом "запрет удаления" (xxx_SHARE_DELETE) специально, чтоб избежать "сюрпризов". Считывался бы код в память целиком - можно было бы удалять и открытые экзюшники. Вот только на момент оздания Win32 экономия памяти была приоритетной задчей, поэтому загрузчик так не делает.
	Wintermute - devnul.ru 23 Aug 2004 2:05 PM
2 plug: Отматывание тредов - 20$
	plug 23 Aug 2004 2:17 PM
2 Wintermute: >>Отматывание тредов - 20$ Вы готовы заплатить? ОК. :) domician:"и вы упоминали про удаление исполняемых файлов в unix-like - что можно удалять когда они запущены..." plug:"это делается очень просто. При удалении файл "вычеркивается" из каталогов ... а вот сами данные на диске ... освобождаются только после того, как завершится последний процесс, их использующий." Wintermute:" Такое же механизм существует в NT с самой первой версии." plug: "А чего ж она им не пользуется?" Wintermute:"Дык она пользуется." plug: почему же тогда "...ни explorer, ни cmd не дают удалить файл <чего-нибудь>.exe, если он в данный момент запущен." Ну так что? Ответ будет? (а 20$ будете должны :-)
	plug 23 Aug 2004 2:50 PM
Нда, что-то в Microsoft ничего не знают о DeleteFileEx. И в списке функций для работы с файлами (http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/fileio/base/file_management_functions.asp) ничего похожего. То ли она такая секретная, то ли Wintermute просто гонит...
	Wintermute - devnul.ru 23 Aug 2004 3:03 PM
2 plug: Цитирую: ""не знал. расскажите плз, как NT позволяет горячее удаление спроецированных в память файлов" Не горячее, а отложенное. DeleteFileEx с флагом отложенного удаления. Название флага - уволь, не помню, надо в SDK смотерть, а его под рукой нет :( Что касается спроецированных на память файлов - так они создаются/открываются с флагом "запрет удаления" (xxx_SHARE_DELETE) специально, чтоб избежать "сюрпризов". Считывался бы код в память целиком - можно было бы удалять и открытые экзюшники. Вот только на момент оздания Win32 экономия памяти была приоритетной задчей, поэтому загрузчик так не делает." Ы? Что касается DeleteFileEx, то да, ты прав, я ошибся, а такой функции нет. Давно пользовался, успел забыть. Для удаления/замены открытых файлов используется вызов MoveFileEx. А почему ею не пользуются Explorer и другие - да потому, что соотвествующий вызов можно делать только администраторам, а Explorer должен работать под любым юзером, планида у него такая.
	Wintermute - devnul.ru 23 Aug 2004 3:04 PM
В догонку - у них теперь есть и ReplaceFile.
	plug 23 Aug 2004 4:13 PM
2 Wintermute: >> Цитирую: ... Ну вот совсем другое дело. И зачем было выпендриваться про "отмотку тредов"? (тем более, что вопрос то мой был раньше этого ответа, сказал бы просто "уже ответил"). Только вот ваш ответ больше вопросов порождает, чем отвечает. Хорошо, есть MoveFileEx. Во-первых, это не совсем чтобы delete, то есть просто удалить нельзя? Ну да ладно. А какой флаг вы имели ввиду? MOVEFILE_DELAY_UNTIL_REBOOT? Как вы сами заметили, это не горячее удаление, а отложенное. А изначальный вопрос был именно про "горячее", и ответ - как именно "горячее" сделано в юниксах. К тому же это отложенное до рестарта, а не завершения процесса. Причем делается так, что "до завершения процесса" его и не расширить. В реестр пишется задание "загружателю ОС" выполнить нужную операцию во время рестарта. (Кстати, из-за этого нужны администраторские привилегии?) Как я понимаю и сам файл при этом никуда не прячется до перезагрузки и соответсвенно заменить его дугим нельзя? Согласитесь - это совсем другой механизм, ничего не имеющий общего с тем, который я описывал. (и с "Такое же механизм существует в NT с самой первой версии." вы немного поторопились. Так?) >>Считывался бы код в память целиком - можно было бы удалять и открытые экзюшники. Вот только на момент оздания Win32 экономия памяти была приоритетной задчей, поэтому загрузчик так не делает Так вот этого нельзя было только "на момент оздания Win32"? Или до сих пор нельзя? То есть, "горячее удаление" как в юнихе до сих пор отсутствует или что-то поменялось? >>А почему ею не пользуются Explorer и другие - да потому, что соотвествующий вызов можно делать только администраторам (Конечно, если для выполнения требуется писать задание в ветку HKEY_LOCAL_MACHINE, то пожалуй без администраторских полномочий не обойтись). Ладно, а если бы можно было хотя бы под администраторм, как бы это выглядело (мне просто любопытно)? Типа "перезагрузите компьютер, чтобы изменения вступили в силу"? :) Или в директории ничего не меняется, но появляется сообщение - "ваше задание успешно поставлено в очередь, когда вы в очередной раз переазгрузите ваш сервер, этого файла здесь не будет"? >> В догонку - у них теперь есть и ReplaceFile. Ну и замечательно. Скорее всего где-то и оно используется. А к "горячему" удалению/замене оно как-то имеет отношение? В описании (которое я взял по ссылке на той же страничке) ничего не сказано о замене файла, в данный момент отображенного в память. Так оно сработает в таком раскладе или вернет ошибку (типа ERROR_UNABLE_TO_REMOVE_REPLACED)? З.Ы. Будем считать, что про 20$ мы оба просто пошутили. :)
	PTO - ptokgb.ru 23 Aug 2004 6:19 PM
2 plug: "Но не торопитесь критиковать, это только один из механизмов и одна из имплементаций" - кайф, только я решил покритиковать, как читаю - критиковать нельзя, ибо есть еще более рулез... а если серьезно, то данная имплементация (которая вошла таки в 2.6) уммет делать асинхрон только на raw-устройства и на файлы, открытые на direct доступ, т.е. мимо ФС... соответственно все ОСные кеши и прочие радости идут по женской линии... Там собственно на страничке что вы привели есть ОЧЕНЬ хороший документ, писанный в IBM Linux TechCenter - очень познавательно... там они собственно ставят вопрос и зачем оно нужно и с какими трудностями они столкнулись чтоб линукс побороть... компромисс к которому они пришли меня правда немного озадачил - типа retry-based model рулит :)... хотя может по-другому и не получится никак
	glassy 24 Aug 2004 8:36 AM
> О, опять крупный программист glassy, не знающий, через какой > механизм работает критикуемый им буфер обмена Windows Крупный программист гласси организовал CTextView на стероидах. Как работает буфер обмена мне пох. Не стану я, в отличие от некоторых, кипятком ссать "я видел апи вин32 для копирования в него текста, это Мегарулез!!!". > скомпрометировала??" > А при чем здесь DDE? Не заставляй меня МСДН открывать. Я такой фигни здесь не держу. > Вот блин... Я только час назд использовал такие объекты, а от > них, оказывается, геморрой... Не у тебя, а у несчастных кодеров :) > Ты вот лучше скажи мне - а как в люликсе картинки из одно > программы в другую вставляются? ASCII art? А музыка? Ноты? В жизни никогда в люликсе картинки не вставлял... Ну не было необходимости (как вообще такая необходимость может возникнуть?). Как вставляет? Нормально вставляет. В вим текст без картинок, в ОО -- и с форматированием и с картинками.
	glassy 24 Aug 2004 8:40 AM
вдогонку > Ты вот лучше скажи мне - а как в люликсе картинки из одно > программы в другую вставляются? ASCII art? А музыка? Ноты? У меня есть подозрения, что это RTF.
	Wintermute - devnul.ru 24 Aug 2004 10:46 AM
2 plug: "Хорошо, есть MoveFileEx. Во-первых, это не совсем чтобы delete, то есть просто удалить нельзя" А какая, в принципе, разница, какой функцией удалять файл? "А какой флаг вы имели ввиду? MOVEFILE_DELAY_UNTIL_REBOOT?" Его. "Как вы сами заметили, это не горячее удаление, а отложенное. А изначальный вопрос был именно про "горячее", и ответ - как именно "горячее" сделано в юниксах" Я же сам писал, что файл процесса открывается с запретом на удаление. Просто потому, что они маппится на память, а не загружается в нее. Грузился бы целиком, вопроса бы не возникало. " тому же это отложенное до рестарта, а не завершения процесса" А вот это уже детали реализации. И хотя они документированы, их можно поменять. Навскидку - фоновая нить, которая периодически проверяет залоченность процессов, пути к файлам которых прописаны в той самой ветке реестра (или еще где). Думаю, можно и более фундаментальное придумать. Вопрос - а надо? "Как я понимаю и сам файл при этом никуда не прячется до перезагрузки и соответсвенно заменить его дугим нельзя?" Вообще-то, файл исполняющегося процеса (я говорю об EXE) можно переименовать (не уверен, что это может сделать простой юзер, но админ - точно). Запускаем программу proga.exe, нужно ее заменить "на ходу" - переименовываем ее в deleteme.bak, копируем на то же место новую версию proga.exe и перезапускаем. Чтобы не забыть удалить deleteme.bak, вызывам MoveFileEx. Все, дело сделано. "Согласитесь - это совсем другой механизм, ничего не имеющий общего с тем, который я описывал" Если судить с точки зрения реализации процесса "горячей подмены" - да. Но с точки зрения результата - просто вид сбоку. "Так вот этого нельзя было только "на момент оздания Win32"? Или до сих пор нельзя? То есть, "горячее удаление" как в юнихе до сих пор отсутствует или что-то поменялось?" Сделать горячую подмену в точности, как в люликсе - было нельзя, сейчас нельзя и никогда будет нельзя. Просто сделать горячую подмену - можно, можно и будет можно. Как - пример привел выше. Еще раз - в Win32 исполняемый код в память не грузится, а (обычно) отображатеся. Тому масса поводов, основной - экономия памяти (требование 8 мегов для NT 3.1 и 4 мегов для Win95). Соотвественно, файл исполняемого кода, в том числе - кода процесса, остается открытым до завершения процесса. Чтобы система могла по требованию подгрузить необходимый код, а не хранить его копию в опреативке или свопе. А чтобы шаловливые ручонки не удалили файл с этим необходимым кодом, файл открывается с запретом удаления. Кстати, сейчас вспомнил - есть вроде флаг линкера/PE, который как раз заставит весь код EXE/DLL целиком загрузить в виртуальную память. Сделано это, вроде бы, чтобы грузить программы с дискет/сети, на случай, если флопик вынут или соединение порвется. Не помню, будет ли при этом закрыт исходный файл, надо в доки смотреть. Т. е., м. б. я и не прав, а можно в точности, как в люликсе. Но я сильно не уверен, что этот флаг был в оригинальной спецификации Win32, а не появился позже. Что касается горячей замены. Запуск процесса в винде - гораздо более дорогостоящая операция, нежели в юниксе. Поэтому программы, которые необходимо "подменять", пишут иначе - вместо подпроцесса пускают нить, экзюшник служит лишь "пускачем", а всю функциональность реализуют в виде DLL/ActiveX. Подменить DLL просто. AFAIK, так IIS работает. "Скорее всего где-то и оно используется. А к "горячему" удалению/замене оно как-то имеет отношение?" Я же сказал - переименовал/переместил старый файл, на его место положил новый. И вообще, в .Net эта проблема отсутствует.
	Wintermute - devnul.ru 24 Aug 2004 10:54 AM
2 glassy: "> А при чем здесь DDE? Не заставляй меня МСДН открывать. Я такой фигни здесь не держу." И все-таки? DDE клипбордом не пользуется. "> них, оказывается, геморрой... Не у тебя, а у несчастных кодеров :)" Уверяю тебя, написать реализацию IDataObject для помещения в клип чего угодно - работа простая, рутинная. Перефразируя Кларка, "тудности и прелести программирования OLE сильно преувеличены". "В жизни никогда в люликсе картинки не вставлял... Ну не было необходимости (как вообще такая необходимость может возникнуть?)" У-у-у, как все запущено... Думаю, что это необходимо почти любому юзеру. Например, я пользуюсь Photoshop, приходится вставлять картинки в слои. Иногда - в документы Word. Иногда - в HTML. Мало ли! "Как вставляет? Нормально вставляет. В вим текст без картинок, в ОО -- и с форматированием и с картинками" Ну, от OO было бы странно ожидать другого. А vim на рабочем месте не-программиста... Не, не верю.
	Wintermute - devnul.ru 24 Aug 2004 11:05 AM
2 plug: Посмотрел MSDN - структура IMAGE_FILE_HEADER, поле Characteristics, флаги IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP и IMAGE_FILE_NET_RUN_FROM_SWAP. Близко, но все-таки не то.
	glassy 24 Aug 2004 12:48 PM
> У-у-у, как все запущено... Думаю, что это необходимо почти любому > юзеру. Например, я пользуюсь Photoshop, приходится вставлять > картинки в слои. Иногда - в документы Word. Иногда - в HTML. Мало > ли! А что, есть какие-то проблемы со вставкой картинок в GIMP, OO или Mozilla Composer?
	plug 24 Aug 2004 1:57 PM
2 Wintermute: Ну вот и ладненько. Спасибо за более менее подробное объяснение "как он в виндовсе" работает. Я только хочу пояснить "как оно в юниксе". В юниксах (вот не скажу точно за линукс, но поскольку один и тот же механизм в System V и BSD, врядли в линухе пошли своим путем) исполняемые файлы тоже отображаются в память, а не грузятся полностью. Более того, на самом нижнем уровне все открытые регулярные файлы просто отображаются, только те, которые открываются не для исполнения, а для чтения/записи, отображаются не в пространство какого-то процесса, а в буферы ядра. А вот удаление открытых кем-то файлов в юниксах совершенно прозрачно. Дело в том, что почти изначально в юниксе блоки данных файла (и таблица размещения) отделены от записей в каталогах. Поскольку разные записи (имена файлов) могут указывать на одни и те же данные, сразу же понадобился механизм для проверки "когда же можно удалить сами данные". Сделан он был элементарно - через счетчики ссылок. Поэтому операция удаления файла в юниксе только вычеркивает его имя из каталога и уменьшает счетчик ссылок. После этого проверяется количество оставшихся ссылок и только если оно равно нулю, освобождаются сами блоки данных. Позднее, когда в юниксах добавили "виртуальную файловую систему" (обобщенную систему для работы с файлами из разных "физических" ФС) тот же метод (подсчет ссылок) применили для открытых файлов. С каждым открытым файлом связана некая общая (для всех процессов) структура, а количество процессов, использующих этот файл просто отражается в счетчике ссылок. Когда все процессы закрывают файл, счетчик доходит до нуля и общий хэндлер можно освобождать. Оставалось только объединить эти процедуры и счетчики. Теперь данные файла считаются актуальными даже если счетчик ссылок из каталогов равен нулю, но не нулевой счетчик использующих файл процессов. И соответственно, при "отцеплении" последнего процесса проверяется не надо ли освободить заодно и блоки данных. Все происходит автоматически без дополнительных фоновых процессов и отложенных заданий. А то, что подобное поведение можно сэмулировать с помощью спецальных "сборщиков мусора" и переименований файлов... ну что ж хорошо, что такой путь возможен. ( Вот правда если бы ситуация была обратная, то есть что-то, было встроенное в NT, но отсутсвовало в линухе. И какой-нибудь линуксоид объяснил, что и там это можно сделать написав специальный сервис и пару нестандартных утилиток... Точно кто-нибудь не удержался бы от "ой, то что в виндовсе автоматически и чуть ли не с рождения, в лялихе можно сделать только костылями и подпорками...". Но я воздержусь от подобных комментариев :-).
	fi 24 Aug 2004 4:44 PM
Как не странно для любителей вин в X11 есть прекрасный гипкий, расширяемый механизм X Inter-Client Communication (icccm) в том числе для перетаскивания из одного окна в другое. Найболее развит он конечно для текста (т.к. в 90% это текст), но работает он для любых объектов.
	domician 25 Aug 2004 12:16 AM
2 plug > к счастью подвернулась подходящая ссылка http://lse.sourceforge.net/io/aio.html Как выясняется оно _только для файлов_ и есть не для всех файлов, а только для тех которые открыты с флагом O_DIRECT... С другой стороны, в NT асинхронное чтение/запись тоже не для любого файла доступны, а тока для тех что открывались с FILE_FLAG_OVERLAPPED... тут надо бы уточнить - в NT файл, открытый в асинхронном режиме, не кэшируется никак? т.е. аналогия получается или нет... и еще нюанс есть - для только что созданных (а не только существующих) файлов в NT тоже можно асинхронно писать/читать > Но не торопитесь критиковать, это только один из механизмов и одна из имплементаций. меня интересует не просто наличие где-то сторонней имплементации, а чтоб имплементация эта была штатной фичей в распространенных дистрах... ну типа берем Мандрейк, Редхат, СуСе - и везде есть по дефолту асинхронный I/O для файлов... как в NT... это правильно - и программеру не надо у себя патчи накладывать, и думать не надо, а есть ли такие патчи на машине пользователя, где будет пакет работать, которому asynchronous I/O требуется > Тем более не выяснив - действительно ли "в линуксе этого нет". я знаю, кое-что уже реализовано (например, в ядре RHEL 3 есть асинх. ИО для raw-partition, sockets)... вопрос в _степени_ поддержки этой фичи, и не только в отдельных дистрах, но вообще в стандартном ядре 2.6 (про 2.4 так уж и быть, забудем... хотя большинство инсталляций линукса пока на этой версии ядра) > Дело в том, что обычный снхронный write для файла пишет только в кэш и тут же завершается. нет, тут не все так просто - иначе б во всех ОС были только кеши, но в некоторых еще и асинхронный ИО есть
	domician 25 Aug 2004 12:17 AM
2 plug > Если он будет возвращаться до копирования, то что здесь можно сэкономить? "Линейное" переписывание из буфера в буфер съедает мало времени (больше потеряете на переключении контекстов). уточните про контексты... чего я там теряю при асинхронном ИО, по сравнению с кэшированием ("линейное переписывание из буфера в буфер" - это ведь из буфера приложения в область системную, тоже без переключения контекстов не обойтись)... а один недостаток вы уже назвали - полное копирование из буфера приложения в буфер кэша... мало времени съедает? а вот это субъективно :) когда куча приложений синхронно что-то пишет, и все это приходится в буфера кэша копировать... > К тому же, чтобы юзерский процесс мог хоть что-нибудь в это время сделать, надо чтобы количество CPU было не просто >1, а сравнимо с количеством активных процессов, поскольку системные приоритеты все равно выше драйверы подсистемы ввода-вывода работают в контексте процесса SYSTEM, а приоритет у него по дефолту _средний_, т.е. такой как у прикладных процессов (тоже по дефолту. можно задать и более высокий приоритет)... потому кол-во ЦПУ вполне достаточно 1... знаете, что-то мне напомнил ваш пример с приоритетами, для коих нужно много ЦПУ... типа вытесняющая многозадачность не нужна на компьютере только с 1 процессором :) > Правда кроме самого копирования может понадобится время для "аллокации" нужного буфера в кэше. вы сами назвали второй недостаток (кроме собсно копирования, еще и буфер в кэше выделять надо) > вы уж излагайте сразу задачу (вот типа "не дожидаться окончания записи в любой файл, а сразу продолжать работу"). Так это и есть задача асинхронного I/O. Конечно он нужен, чтобы сэкономить время ожидания до завершения медленного ввода-вывода на внешние устройства. > Вот искать - насколько они реализованы в линухе, мне лень. Если вам интерсно - сами найдете не, ну так не пойдет. сначала говорите что есть, потом не уверены что это реализовано, и в какой степени. давайте поточнее... еще вопрос вам - перечислите плз какие есть в линуксе объекты синхронизации
	domician 25 Aug 2004 12:17 AM
2 VicTor > очень часто стандартный обработчик сообщений, обрабатывая какое-либо сообщение, генерирует еще несколько сообщений. Некоторые из них передаются методом SEND, другие - POST. Согласен. Но как я уже говорил, и без активного фокуса в системе происходит интенсивная посылка/обработка сообщений, и что-то я сомневаюсь, что включение Active Focus эту интенсивность повышает раза в два > при смене фокуса генерируется последовательность сообщений, в которой WM_ACTIVATE может передаваться как методом POST, так и методом SEND, а WM_PAINT - всегда методом POST. ну, всего-то двум окнам система должна послать WM_ACTIVATE, причем если окна эти принадлежат разным программам (разные очереди ввода), то WM_ACTIVATE будет именно асинхронным (кстати, я сомневаюсь, что каждое приложение _обрабатывает_ WM_ACTIVATE, а тогда система просто поднимет поверх всех то окно, на которое перемещается курсор)... а почему WM_PAINT "всегда методом POST"? оно может быть асинхронным... например, при инициализации Win32-приложения первое для него сообщение WM_PAINT от системы - именно асинхронное... но допустим, если даже все сообщения синхронные, идут через очереди двух приложений, то какие у вас факты, что интенсивность потока сообщений в системе сильно возрастает, если активный фокус включить? а если просто мышкой подвигать по окну (без Active Focus) ? приложение тогда получит кучу сообщений WM_MOUSEMOVE... только мне кажется, что система и приложения легко с ними справятся и юзер ничего не заметит
	domician 25 Aug 2004 12:17 AM
2 glassy > В линуксе для текста == один буфер, для картинок -- другой, для просто значений цветов -- третий, для файлов и папок -- четвертый. Что ты привязался к этим будферам обмена? снова ответ в духе glassy :) чего я привязался к буферу? мало мне кидать через буфер только текст - объекты хоцца :) Буфера для картинок и файлов в линуксе есть? о, рассказывай плиз, как мне ими пользоваться... а то понимаешь беда в КДЕ, что с клиппером что без него - ну не получается через буфер ничего кроме текста перекинуть... я как это увидел - не поверил сначала, думал где-то что-то включить надо... ну, галочку там поставить в Центре управления КДЕ, или параметр какой поправить в конфиге... однако линуксойды которых я пытал насчет буфера, сначала отмалчивались, а потом стали доказывать что кроме текста и не надо ничего кидать через клипборд :) и тут мне стало весело :) >> Их наваять -- как два пальца об асфальт. Хочешь -- через юникс сокеты, хочешь, через TCP/IP, хочешь, через иксовые атомы. имея такую продвинутую среду КДЕ - мне еще и буфера ваять надо? :) а если так просто приспособить буфер для кидания объектов, почему интересно разработчики КДЕ это не сделали? 2 PTO как вы прокомментируете "readiness signals + non-blocking IO" - это можно считать аналогом асинхронного I/O в NT (с учетом его основной цели - не ждать, пока выполнится медленный I/O)? насчет открытия в линуксе файла с флагом O_DIRECT - это тоже самое что открыть в NT файл с FILE_FLAG_OVERLAPPED ? или совсем разные вещи? да, кэш не участвует при O_DIRECT, но вроде и в NT асинхронное чтение/запись идет мимо кэша... или не мимо? (у Рихтера упоминается, что асинхронные запросы ставятся в очередь в системный буфер - это один из буферов кэша или нет?) и что вы скажете насчет _синхронной_записи_ в кэш? с одной стороны, вроде бы синхронный вывод + кэш это другой вид асинхронности - отложенная запись... но ведь когда приложение явно пишет асинхронно что-то в файл, запись начинается тоже НЕ СРАЗУ при вызове WriteFile, система ставит асинхронный запрос в очередь, а потом сама выбирает момент записи... почти как с кэшем... что же получается? синхронный вывод + кэш - почти аналог асинхронной записи? разве что когда запись из кэша на диск закончится, система - в отличие от асинхронного I/O - не уведомляет приложение, и об ошибках не сообщает, если таковые возникли. P.S. а что там со сравнением баз на форуме КГ? все затихло... тесты СУБД отменяются? и Апач с перлом против ИИСа?
	Алексей 25 Aug 2004 1:30 AM
я наверно чего-то не понимаю, но в линуксе (и прочих *нуксах) всё асинхронное делается одинаково просто -- fork.
	plug 25 Aug 2004 8:28 AM
2 domician: >>не для всех файлов, а только для тех которые открыты с флагом O_DIRECT... Ну так вы пока не ответили - есть ли смысл делать AIO для не-DIRECT файлов. Ждете пока РТО вам это "разжует"? >> и еще нюанс есть - для только что созданных (а не только существующих) файлов в NT тоже можно асинхронно писать/читать А где вы нашли, что в линуксе можно для "только существующих"? Это вас "...read and write on files opened with ..." на такую мысль навело? Дело в том, что в большинстве юниксов нет syscall'а create_file (прикинь, да, в линухе оказывается новый файл вообще создать нельзя :-). Создание файлов делается тем же open(), только с флагом O_CREAT. Поэтому никто не будет специально подчеркивать, что "для файлов opened with and without O_CREAT...", за исключением тех случаев, когда действительно есть разница. >> меня интересует не просто наличие где-то сторонней имплементации, а чтоб имплементация эта была штатной фичей в распространенных дистрах... Ну что ж, резонно... если вы собрались писать что-то и хотите, чтобы оно было абсолютно переносимо. А если просто "порадеть за всех девелоперов"... ладно, воздержусь от оценки. :) >> вопрос в _степени_ поддержки этой фичи, и не только в отдельных дистрах, но вообще в стандартном ядре 2.6... Ну хорошо, забудем про остальные имплементации. Вот та, что описана в приведенной ссылке, должна быть в каждом 2.6. Так пойдет? (Хотя, ну что тут поделать. Нету единой фирмы "Линукс". Если RH, решит, что его имплементация лучше, врядли он будет распространять ту, что принята стандартной в kernel 2.6.) >> нет, тут не все так просто - иначе б во всех ОС были только кеши, но в некоторых еще и асинхронный ИО есть Так конечно, I/O же не ограничивается регулярными буферированными файлами. Есть еще сокеты и пайпы, где чтение по определению асинхронно, а запись может быть асинхронной в определенных обстоятельствах. И файл может быть открыт прямо на устройство В/В (точнее - драйвер). Кстати, это posix AIO относится к REALTIME расширению. То есть, больше предназначен для считывания информации с внешних датчиков и записи команд на "манипуляторы". Понятно, что если ОС претендует на "риэлтаймовость", ей именно этот API необходим. А если только буферированные файлы писать/читать, то ... мы пока так и не выяснили - надо ли. :) А что касается сокетов/пайпов, то _все_ юниксы поддерживают non-blocking сисколы + select/poll (+ некоторые - epoll/kqueue). Ну и я уже упоминал readiness signals (только вы сами их сравнить не можете, к РТО побежали консультироваться :). Я же говорю - определитесь с задачей. Кого-то может любая существующая ФС не устраивать (не по фичам, а скажем по скрости), значит нужен AIO на raw-device. Кому-то, нужно бысто управлять станком каким-нибудь, значит - AIO непосредственно с драйвером (тот самый DIRECT). А кому-то просто - "хочу чтобы было в точности как в NT". :)
	plug 25 Aug 2004 10:01 AM
2 domician: >> уточните про контексты... чего я там теряю при асинхронном ИО, по сравнению с кэшированием ("линейное переписывание из буфера в буфер" - это ведь из буфера приложения в область системную, тоже без переключения контекстов не обойтись)... (Я вообще-то не архитектор ядер ОС. Обсуждаю вещи вроде бы на "общеобразовательном" уровне. Страно, что здесь что-то непонятно. :) Хорошо, давайте считать... Вот есть два write сискола, одни sync, другой async. Оба должны сначала переключиться в контекст ядра. В юниксе при этом пространство задачи со своими буферами уже доступно по определению. Для sync'а возможно понадобится смапировать буфер файла, но для async нужен также буфер очереди куда он будет задание писать. Так что эти этапы можно считать равными и не учитывать. Далее начинается различие. Синхронный начинает линейное копирование, после которого обратно переключает контекст в задачу. Асинхронный сразу переключает контекст (опять же равные части, можно вычесть из обоих случаев). То есть до этого момента async сэкономил только "переписывание". А вот что будет потом, после async'а. Вам же надо знать об окончании процедуры. Значит либо процесс вызывает какой-нибудь read_event/wait_for_something/aio_return, либо ядро само запускает юзерскую "процедуру завершения" (по posix AIO - либо обработчик сигнала, либо thread). В первом случае надо "занырнуть" в контекст ядра и вернуться обратно (два переключения), во втором - ядро должно переключится в контекст задачи, выполнить процедурку и вернуться обратно. Вот этих переклюяений в случае с sync вообще нет. Вот и надо определиться, что напряжнее - переписывание монолитного куска памяти или два дополнительных переключения контекста. Да, в случае с DIRECT, понятно, что кроме переписывания еще дополнительное время пока сама "железка" (винт) операцию отработает. Понятно, что оно все остальные расходы перекрывает. >> а один недостаток вы уже назвали - полное копирование из буфера приложения в буфер кэша А что, при асинхронном I/O в буферированный файл этого не будет? (При "async в DIRECT" _возможно_ данные и перепишутся по DMA прямо из юзерского буфера в дивайс, но мы то сравниваем не DIRECT.) Так что это не недостаток, это присутсвует в обоих случаях. >> когда куча приложений синхронно что-то пишет, и все это приходится в буфера кэша копировать Куда-то вас не туда понесло. А когда куча приложений _а_синхронно что-то пишет. Куда копирование денется? Давайте сравнивать одиночное копирование sync и async "при прочих равных". >> драйверы подсистемы ввода-вывода работают в контексте процесса SYSTEM, а приоритет у него по дефолту _средний_, т.е. такой как у прикладных процессов В юниксах приоритет всех системных процессов больше чем любой юзерский. Он перекрывается только realtime'овым (там где таковой есть). (Вы конечно можете пообсуждать - где приоритеты расставлены правильнее, в юниксах или NT. Но это уже другая тема. В контексте обсуждения AIO придется считаться с традициями конкретной ОС.) >> потому кол-во ЦПУ вполне достаточно 1 Вы этого не обосновали. Для выигрыша от async (напоминаю - речь идет о буферированном выводе) надо чтобы приоритет задачи был хоть на ступеньку выше, чем приоритет того системного процесса, который будет буферы копировать. В юниксах это точно не так, а "в других ОС" как вы сказали - такой же. То есть отработает тот, кто в очереди на исполнение впереди окажется. :)
	plug 25 Aug 2004 10:31 AM
2 domician: >> знаете, что-то мне напомнил ваш пример с приоритетами, для коих нужно много ЦПУ... типа вытесняющая многозадачность не нужна на компьютере только с 1 процессором :) Где вы такие глупости собираете? (для одного процессора она как раз нужнее.) И что за замысловатые ассоциации у вас? :) (Не могу представить, как мои рассуждения о приоритетах связаны с этой глупостью. Или это просто все, что вы можете вспомнить, при слове "приоритет" :-) >>вы сами назвали второй недостаток (кроме собсно копирования, еще и буфер в кэше выделять надо) Ну да, недостаток. Но мы же сравниваем "где лучше/хуже" (и хотелось бы чтобы "лучше" было не на 0.01%), а не "где есть недостатки и где их вооще нету". Дополнительный буфер может и не понадобится, если понадобится, но с free pages pool все в порядке, то опять же время мизерное. Худший случай - когда машина сильно нагружена и free pages приходится использовать "прямо с колес", то есть отбирая у других буферов и процессов. Но в этом случае и у самого процесса, который собирался "сделать что-нибудь полезное" дожидаясь завершения I/O, скорее всего проблемы возникнут. Кроме того, буфер может понадобиться и для самого задания AIO в очереди. Понятно, что размеры несравнимые, но все таки... >> Так это и есть задача асинхронного I/O. Конечно он нужен, чтобы сэкономить время ожидания до завершения медленного ввода-вывода на внешние устройства. Ну хорошо, если задача формулируется в таком общем виде, то надо рассматривать все доступные механизмы - non-blocking I/O + select/poll, SIGIO (те самые readiness), и собственно AIO. Какой идиот вам сказал, что ни один из них до сих пор в линухе не реализован? :) >> не, ну так не пойдет. сначала говорите что есть, потом не уверены что это реализовано, и в какой степени. давайте поточнее... еще вопрос вам - перечислите плз какие есть в линуксе объекты синхронизации Аха. А так значится пойдет: "...а есть, ли в линухе асинхронный IO" - "Есть" - "А он _точно_ для файлов" - "Точно - вот ссылка" - "А он точно _везде_ есть" - "Точно - там же написано" - "а..,а..., а какие объекты синхронизации там есть...". Тут уж, дарагой мой, domician, предложение "пешего эротического путешествия" напрашивается. :) Мне вообще-то состяние дел в линухе "глубоко фиолетово". Я для него не пишу и даже нигде не ипользую. Мне просто почудилось, что человек искренне интересуется некоторыми механизмами юниксов. А оно оказыватся, что он с красными (от азарта) глазами все ищет еще какой-нибудь повод "опустить" конкретно нелюбимую операционку. Вас сильно удивит факт, что не все хотят втягиваться в вашу игру? :) Если вы хотите подробного и аргументированного обзора "как и насколько это реализовано в различных дистрибутивах Линукса" (вы хоть представляете - сколько их вообще существует) ... давайте по деловому. Я поразворачиваю у себя разные дистрибутивы, почитаю документацию на конкретные патчи, погоняю тесты (вдруг RELEASE.NOTES что-то приукрашивают), подберу цитаты из "сорсов". А вы это изыскание оплатите. Сколько можете предложить? Или просто побежите на другие форумы врать типа "я вежливо спрашивал линуксоидов - есть ли у них асинхронный IO, а они (вместо подробного аргументированного отчета) начинают 'отмазки лепить', бабки какие-то требовать ... линурасы одним словом"? :)
	Wintermute - devnul.ru 25 Aug 2004 11:14 AM
2plug: "все открытые регулярные файлы просто отображаются, только те, которые открываются не для исполнения, а для чтения/записи, отображаются не в пространство какого-то процесса, а в буферы ядра" Полагаю, что в винде (NT) файловая система действует точно также. Хотя я не гуру по ядру. "блоки данных файла (и таблица размещения) отделены от записей в каталогах" Ну, в NTFS тоже самое. И hard links, описанные ниже, тоже есть (и были с самого начала). "освобождаются сами блоки данных" А как с этим дело обстоит на FAT? Ведь в ней же принципиально "одна зпись в каталогк - один файл" "общая (для всех процессов) структура, а количество процессов, использующих этот файл просто отражается в счетчике ссылок. Когда все процессы закрывают файл, счетчик доходит до нуля и общий хэндлер можно освобождать" Вот тут в NT тоже самое. Файл с точки зрения системы - объект ядра со счетчиком ссылок, ассоцированный с данными на диске. И не только на диске, так как бывают "безымянные" файлы, файлы в памяти и т.п. Кстати, есть и файлы-самоубийцы, дисковые файлы, которые автоматически удаляются после закрытия. "Все происходит автоматически без дополнительных фоновых процессов и отложенных заданий" Учитывая, что сделать это несложно и что, по крайней мере, частично это уже сделано, я не могу сказать, почему NT работает иначе. Видимо, был резон. Говорить, что в MS поленились я не могу, так как hard links и многое другое, что реально стало использоваться их софтом только в Win2k, они реализовали еще в 92 году. "спецальных "сборщиков мусора" и переименований файлов... ну что ж хорошо, что такой путь возможен" Вообще-то, речь шла про "горячую" подмену исполняемых файлов и DLL. Механизм MoveFileEx, как мне кажется, больше подходит для программ-установщиков. В повседневной жизни такая подмена не нужна, и в юниксе тоже.
	VicTor 25 Aug 2004 11:14 AM
2 domician: >> при смене фокуса генерируется последовательность сообщений, в которой WM_ACTIVATE может передаваться как методом POST, так и методом SEND, а WM_PAINT - всегда методом POST. > ну, всего-то двум окнам система должна послать WM_ACTIVATE, причем если окна эти принадлежат разным программам (разные очереди ввода), то WM_ACTIVATE будет именно асинхронным А в той последовательности присутствуют не только WM_ACTIVATE и WM_PAINT. Там может быть до десятка сообщений в зависимости от ситуации. > (кстати, я сомневаюсь, что каждое приложение _обрабатывает_ WM_ACTIVATE, а тогда система просто поднимет поверх всех то окно, на которое перемещается курсор)... Конечно, обрабатывает. Что там в хвосте оконной процедуры вызывается? DefWindowProc()? > а почему WM_PAINT "всегда методом POST"? оно может быть асинхронным... например, при инициализации Win32-приложения первое для него сообщение WM_PAINT от системы - именно асинхронное... А про WM_PAINT есть специальная оговорка, непозволяющая считать, что даже при инициализации отправка этого сообщения будет асинхронной. > а если просто мышкой подвигать по окну (без Active Focus) ? приложение тогда получит кучу сообщений WM_MOUSEMOVE... Конечно. Но с активным фокусом каждое сообщение WM_MOUSEMOVE тянет за собой "паровоз" из других сообщений. А как вы уже говорили, "и без активного фокуса в системе происходит интенсивная посылка/обработка сообщений,"
	Wintermute - devnul.ru 25 Aug 2004 11:22 AM
2 glassy: "А что, есть какие-то проблемы со вставкой картинок в GIMP, OO или Mozilla Composer" Без понятия, bro. Уверен, что под виндой и у первого, и у последнего проблем нет, так как, volens nolens, они должны подчиняться "правилам игры".
	plug 25 Aug 2004 12:24 PM
2 Wintermute: >>Полагаю, что в винде (NT) файловая система действует точно также. Да я охотно верю. Это же выглядит вполне логичным и удобным. Вообще, вы заметили, что современные операционки по крайней мере на уровне основных пардигм и механизмов все больше нивелируются? Все больше сходства, чем различий. >> И hard links, описанные ниже, тоже есть (и были с самого начала). Знаю. :) >> А как с этим дело обстоит на FAT? Ведь в ней же принципиально "одна зпись в каталогк - один файл" Так она же "не родная". :) Попытка создать на ней хардлинк, скрее всего просто "обломается". Ну а на каком-то промежуточном уровне в ядре, наверное, эмулируется счетчик ссылок, но он просто всегда 1, и при удалении единственного имени сразу следует удаление и файла. Я просто хотел сказать, что ... изначально принятое в юниксе разделение имени и данных файла сразу привело к тому, что удаление самих данных не обязательно следует за процедурой "удалить файл". Ну а потом его логично распространили и на открытые файлы. >> Вот тут в NT тоже самое. Файл с точки зрения системы - объект ядра со счетчиком ссылок, ассоцированный с данными на диске. Вот-вот. Я же говорю - общих черт гораздо больше, чем различий. >> Учитывая, что сделать это несложно и что, по крайней мере, частично это уже сделано, я не могу сказать, почему NT работает иначе. Я тоже не могу догадаться. (Может быть мы оба не замечаем какой-то возможной опасности.) Согласитесь, вопрос "почему же она им не пользуется" возник вполне резонно. :) >> В повседневной жизни такая подмена не нужна, и в юниксе тоже. Да может быть и так, спорить не буду. Началось то с того, что domician задал очень общий вопрос - "как вообще можно удалять файл работающего приложения, если он отображается, а не грузится полностью в память". Я как мог объяснил - как это (по крайней мере внешний эффект) получается в юниксах. Там, кстати, другие забавные ньюансы есть. Удаление файла "на ходу" вполне безболезненно. А вот запись прямо в него, естественно не приводит к сохранению старого содержимого и представляет собой реальную опасность для процесса. Любопытно, что BSD действительно блокирует такие попытки (попытка открыть на запись файл, который в данный момент открыт на исполнение, завершается с ошибкой), а вот Solaris, похоже разрешает (не приняв никаких мер предосторожности. Ну да ладно, со временем и это "устаканится". :)
	PTO - ptokgb.ru 25 Aug 2004 3:18 PM
2 plug: разговор зашел про асинхронный ввод-вывод в _ЛИНУКСЕ_... к чему ваши рассказы про то, как сие работает в ЮНИКСЕ? я что-то не помню, чтобы кто-то здесь говорил что настоящий Юникс это плохо (да и про Линукс такого редко говорят тут)...
	fi 25 Aug 2004 4:16 PM
Если нужен AIO для буферизированных файлов, то реализуется это слету: pthread_create, read/write, message, pthread_exit (кстати, так делается в OS/2 и наверно и в НТ, внутри read/write, то есть без pthread не бывает) И еще, вместо pthread_create можно clone. Так о чем спор?
	fi 25 Aug 2004 4:17 PM
то PTO правильно, нужно писать unix-like ;-)))
	plug 26 Aug 2004 9:53 AM
2 РТО: >> я что-то не помню, чтобы кто-то здесь говорил что настоящий Юникс это плохо (да и про Линукс такого редко говорят тут)... О! Занесу ка я это в "избранное". Может еще не раз пригодится. :) >> разговор зашел про асинхронный ввод-вывод в _ЛИНУКСЕ_... к чему ваши рассказы про то, как сие работает в ЮНИКСЕ? А вот это мимо. Где же это я "от темы уклонился"? Разговор то больше шел "про асинхронный ввод-вывод" вообще. Я тут который день прошу объяснить (не для линуха, а просто "на пАльцах" для любой мало мальски знакомой ОС) - какой же смысл в асинхронном IO для обычных кэшированных файлов? Что оно может дать (я уже даже не спрашиваю _насколько_)? Где я там упоминал что-то, что есть в юниксе, но не в линуксе? Про open+CREATE? Так поверьте - в линуксе точно также. Про переключения контекста, free pages pool? Так это не только в линуксе/юниксе, в любой современной ОС так. Про SIGIO? Так тут наоборот - в "солярке" нету, в фрибсд есть, но по сравнению с линухом - урезанный. Оно только в линуксе "в полный рост" и есть. А уж про select/poll/epoll ... так что уж Кегелю не верить? Он и ссылки дает и тесты приводит. Что касается документика от "айбиэмеров", так мы его и не обсуждали. Ну сделали они как считали нужным и ладно. Более того, пока домишин тут тупил насчет контекстов и количества CPU, а вы просто молчали, я даже в MSDN нашел цитатку, что мол "выигрыш от асинхронного IO на файлах может быть получится, если вы что-то типа database целиком с места на место перекладываете, а на обычных вводах/выводах вы получите ухудшение производительности", ... вот именно за счет лишних действий на по проверке завершения. Так может быть не будем хаять айбиэмеров за то, что они не стали прикручивать AIO туда, где это бесполезно или даже вредно, а сосредоточились на тех местах, где это имело смысл (чтобы tune его in the way that is optimum for asynchronous I/O patterns)? (Обратите внимание, они же не сделали так, что AIO вообще не работает с буферированными файлами. Просто в таких случаях молчком выполняется нормальный синхронный IO, а для пркладного программера ничего не меняется. Все равно же прироста производительности нет.) А что касается назойливых вопросов domician'а, так он и не спрашивал "как оно в линуксе устроено". Спросил "правда ли что есть". Ну я подумал - может правда помогу человеку найти. Зашел на opennet.ru в MAN'ы, нашел подходящие страницы, выснил, что "The asynchronous I/O system calls first appeared in Linux 2.5, August 2002.". Так ведь ему оказывается не это надо было. Ему жалко стало, что его классный аргумент "в Линкусе Async I/O НЕТ!" (который он уже по разным форумам приводил) уже устарел. Вот и пошла волынка - "а вы уверены, что он для файлов...", "а вы уверены, что он везде есть...", "а вы уверены, что ....". Да конечно я не уверен. Я просто читаю документацию, там говорят - "...есть; ...для файлов; ...везде; ...и работает". Что я их перепроверять должен? ( Может быть мне к вам с аналогичными вопросами про async IO в NT пристать? "А оно там правда есть"? "И для файлов"? "И во всех версиях работает, включая все сервиспаки"? "А вы сами проверяли"? А то в MSDN что-то написно, а вдруг - неправда. :)) И что, я хоть где-нибудь "разговор перевел"? Мол "не знаю как в SUSE", а вот в AIX... :) Так что вы это ... или покажите то место, где я явно "перевел с линукса на юникс", или оставьте себе эти претезии.
	Wintermute - devnul.ru 26 Aug 2004 1:26 PM
2 plug: "Это же выглядит вполне логичным и удобным" Логичным - хотя бы потому, что работу с файлами можно переложить на менеджер VM и не плодить сущности. "Вообще, вы заметили, что современные операционки по крайней мере на уровне основных пардигм и механизмов все больше нивелируются" На уровне _некоторых_ основных парадигм. Которые выжили в результате "естественного" отбора. Неудивительно, что, например, все (большинство) современных осей поддерживают виртуальную память и ядерные нити - сколько лет шло "вылизывание" именно этих парадигм. Но все же большинство парадигм виндов отсуствуют в юниксе и наоборот. Мне кажется диким представление программы как "черного ящика с одним входом и двумя выходами", юниксоидам - как "объекта со свойствами и событиями". Что, тем не менее, не мешает мне пользоваться sed'ом, а юниксоидам - CORBA. "Так она же "не родная". :) Попытка создать на ней хардлинк, скрее всего просто "обломается"" Под NT - обламывается. А вот под OS/2 (слыхал, сам не видел) - можно делать. "на каком-то промежуточном уровне... эмулируется счетчик ссылок" Хм, логично. "Согласитесь, вопрос "почему же она им не пользуется" возник вполне резонно" ??? Выше моего понимания. Я, кстати, вспомнил, как в 95 или 96 году мне нужно было удалять файл исполняемой программы из самой этой программы :) Причем под 95, где MoveFileEx, по крайне мере, в те времена, отсутствовал. Решение было на редкость прямолинейным и должно работать до сих пор - программа запускала .bat-файл (именно .bat), который по циклу пытался удалить файл программы. Как только он это делал, то удалял сам себя, command.com позволял такие шутки. Так чта-а-а... Вариантов решения одной и той же задачи может быть много. "Да может быть и так, спорить не буду" Нужна инсталляторам, я хотел сказать. И ряду весьма специфических программ, типа IIS. "и представляет собой реальную опасность для процесса" Так по этому-то в NT файл шарится от удаления - Win32-экзюшник - не только код, но и ресурсы, изменение которых "на лету" может привести к таким "сюрпризам"... "а вот Solaris, похоже разрешает" А вот в это я не верю. Не могли сановцы такое допустить, у тамошних программеров очень высокая квалификация.
	Вlack fon.* 26 Aug 2004 2:57 PM
не поял насчто CORBA? >>> а юниксоидам - CORBA.>>> в этой вфразе прслеживате мыслть что CORBA для unix не родное???... CORBA как раз родное.. ( хотя более родное для всех -другео дело что MS ее не подержало потмоу ка понял что сомжет сделать МОНОПЛИЗМ НА .net ).. а напсчт черных ящиков вообще не понялно и свойст и прочих???? что имелсот в виду команда старока Linuxа и stdin sdout??? а в виндах Это DDE/OLE что ли ...? аналогия.. свзи вообещ не вижу. зато сова то каие умные парадигма.. жуть какая то... Ноо вооьбще более намешанйо дури я не читал..( НО ПИСАЛ :)...
	Вlack fon.* 26 Aug 2004 3:01 PM
а срешения удаляние EXE это вообще перл :)... нет решан конечно прикольное.. но чего только не придумаю winдухяткие вместо того что бы ползовать нормально операционкой...:) и скати очень понимаю зачем нужно было удаления для ТИПА ЗАЩИТЫ.. НО ЗАТО какая дырыща открвате для потенциального взломщина это ЗАЩИТЫ.. и вот так все виндазх делаем защиту... Но про то что дырку делает в результате не думаем. номально иттак соейдет.. такоей дура я больше не пишу.
	fi 30 Aug 2004 8:33 AM
to Wintermute > "а вот Solaris, похоже разрешает" > А вот в это я не верю. Не могли сановцы такое допустить, > у тамошних программеров очень высокая квалификация. Solaris это древнее старьё в плане системы. И это один из многих примеров: sun280# cp /usr/local/bin/nedit /tmp/ sun280# ls -l /tmp/nedit -rwxr-xr-x 1 root other 912122 Aug 30 11:31 /tmp/nedit* sun280# /tmp/nedit &amp; [1] 20579 sun280# lsof /tmp/nedit COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nedit 20579 root txt VREG 0,2 912122 8134739 /tmp/nedit sun280# cat > /tmp/nedit qqqq sun280# lsof /tmp/nedit COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nedit 20579 root txt VREG 0,2 5 8134739 /tmp/nedit sun280# ls -l /tmp/nedit -rwxr-xr-x 1 root other 5 Aug 30 11:32 /tmp/nedit* sun280# [1]+ Bus Error (core dumped) /tmp/nedit
	fi 30 Aug 2004 8:35 AM
> Что, тем не менее, не мешает мне пользоваться sed'ом, а юниксоидам - CORBA. Первая практическая реализация была на Dec OSF/1 в 1992 году. А что в WinXXX уже что-то есть?;-)))
	AT - 220220pager.icq.com 30 Aug 2004 10:44 PM
FILE_FLAG_OVERLAPPED ? Это никакого отношения к кешированию не имеет. Это играет роль только как программа может осуществлять чтение - синхронно или асинхронно. А вот FILE_FLAG_WRITE_THROUGH и FILE_FLAG_NO_BUFFERING уже указывает как кешировать данные при чтении или записи. Вот если все вместе обьединить - асинхронное и без кеширования - то "максимальную" производительность полчить можно, но это только для "правильных" программ которые будут читать и писать блоками. А просто асинхронное чтение/запись - так там кеши исспользуються по полной !!
	Knorr 31 Aug 2004 4:45 PM
Все эти фишечки, рюшечки давно реализованиы в BeFS
	Wintermute - devnul.ru 31 Aug 2004 4:53 PM
2 Вlack fon.*: "не поял насчто CORBA?" Ты не понял только одно утверждение - насчет CORBA. Но знал бы ты, как трудно понять любое твое утверждение! Поясняю - да, я говорил об stdin/stdout как о стандартном средстве юникс. Оно было адекватным временам перфорлент и цепных принтеров, но изрядно устарело с тех пор. Однако ж епляются... CORBA, объектная технология конца XX века, не родная для юникса, но на нем работает, как и под виндами.
	Wintermute - devnul.ru 31 Aug 2004 5:00 PM
2 fi: "Первая практическая реализация была на Dec OSF/1 в 1992 году. А что в WinXXX уже что-то есть?;-)))" Вы, батенька, БЕЗНАДЕЖНО отстали от жизни. В 1990 году в виндах во всю использовалась объектно-ориентированая технодогия OLE1 (да, кривенькая-косенькая, но работала), были в качестве дополнения либы+SDK OLE2 с поддержкой протокола COM. Насчет CORBA я не уверен, но году в 94 наблюдал на Борландовской презентации, как CORBA-клиент под виндами общался в сервером на UnixWare.
	Wintermute - devnul.ru 31 Aug 2004 5:03 PM
2 Knorr: "Все эти фишечки, рюшечки давно реализованиы в BeFS" Во-первых, не BeFS, а BFS. А во-вторых, в NTFS "это" (атрибуты с индексацией, дополнительные потоки данных) было с рождения. NTFS, если память не изменяет, 93 год. Другой вопрос, что, видимо, по соображениям совместимости, все это стало активно использоваться Микрософтом относительно недавно.
	Станислав - killa1987mail.ru 31 Jan 2005 4:26 AM
Можно ли создать в ХР вид папки, чтобы в ней была картинка, задать определённый цвет шрифта? Если да, то как? Спасибо