Здравствуйте, The Lex, Вы писали:

TL>Здравствуйте, kochetkov.vladimir, Вы писали:

TL>>>Проходила недавно совсем. По другой теме. Мол у HP "железо все насквозь свое и ни с чем больше несовместимое". Имф был развенчан людями, работавшими с этим железом своими же руками. имхо, тебе тоже следовало бы к оным относиться. Ежели это не так — это, имхо, проблемы не мои, не HP, и не hpux-а.

KV>>Если ты о нашей недавней дискуссии с DOOM'ом здесь, на тему железа HP, то там речь совсем не о "которое не фига не x86" шла

TL> вроде как hpux на xeon запускается.

Да я ХЗ — я с proliant'ами на xeon'ах плотно работал, но только на винде. С HP-UX — вообще не сталкивался

TL>А о чем мы вообще? А — про то что винда не в сорцах.

*оглядываясь* да тут вроде — все про это, но нить разговора я тоже явно потерял...

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, The Lex, Вы писали:

LVV>[]
LVV>Опускаю.

он меня опустил!!!

TL>>Дедушка, освободи лыжню и езжай на дачу билдить ОпенОффис — будет тебе щасте!
TL>>Без обид — в контексте предыдущего сказано.
LVV>Ну, ты тоже тут будешь. И дай тебе Бог чувствовать себя, как я...

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

LVV>А мне не нужно бороться, я не бизнесмен, я нормальный потребитель, и за свои деньги хочу нормального продукта. А МС конкретно ВРЕТ и обманыват — всей своей рекламой. Так что я против обманщиков.

А вот это уже другой и уже как раз практический вопрос: да, винда таки сакс. Как бороться? Открыть код и править ее всем миром? Имхо, зачем? Есть линукс — уже открытый и уже не требующий для сборки какой-то специализированной build-farm — почему бы не направить усилия на агитацию "за", а не "против"? Имхо, создавая достойную альтернативу можно заставить мс а) подтянуться в своем качестве; б) таки считаться с другими и делиться своими интерфейсами. _Интерфейсами_ — не кодом! имхо.

TL>>Опять-таки непонятно почему стоит столько вони насчет мелкософта, если в наличии имеется море альтернатив — бесплатных, с открытым кодом, качественных, и вообще!
LVV>Я лично не могу на работе переставить вместо винды никсы. Политика нашей конторы такая. А политика конторы определяется политикой вышестоящих органов.

Тут я не очень в курсе.

LVV>>>... Качества не только с точки зрения отсутствия ошибок. Но и с точки зрения удобства и скорости работы. А также объемов программ. Например, как было на PDP-11. На 256К сидело 4 пользователя одновременно. По сравнению с персоналкой отсутствовала только графика, да принтер был попроще.
TL>>А терминальная часть там разве не на отдельный процессорных модулях была?
LVV>Я не об аппаратуре. ОСИ были не в пример качественнее винды. Хотя тоже продавались за деньги.

Хм. Вот тут немножко не согласен, поскольку и сам с оными сталкивался: да, оси были попроще — и за счет этого ее можно было "распечатать и посмотреть багу" — но баги точно так же были и точно так же были "специальные решения" — в простонародье "костыли". Хотя и за некоторые — если не большинство — оных сегодня и можно ставить памятник за изобретательность.

TL>>имхо, если вы, "виндоненависники", будете агитировать за опен-сорс ссылками "было на PDP-11 на 256К сидело 4 пользователя одновременно" — простой народ компьютерный — как дачники, так и бизнес — покрутит пальцем у виска и уйдет к МС.
LVV>Таки не поняли, что не против винды, а против вранья и навязывания не нужных мне вещей, за которые еще и бабки вынуждают платить. Неужели вы, такой продвинутый, этого не видите?

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

TL>>У тебе длиннее! Значит винда — сакс! Предлагаю всем отказаться от ее использования!
LVV>Демагогия. Если не глупость. Надеюсь, что нет.

Глупость-глупость! Со стороны своей глупости не вижу причин отказаться от использования некачественного продукта, поскольку альтернативы есть.

Или таких таких нет?

Здравствуйте, Sinclair, Вы писали:

S>>>Скорее речь идет о тупом использовании — т.е. вы не смогли понять, что такое random access, описанный в документации
CC>>Расскажите же мне, тупому, какие ценные сведения о поведении системы вы вынесли из сего исчерпывающего описания? Только не надо отмазок "будет лучше кэшировать" и т.п.
S>В частности, система не будет использовать упреждающее чтение, зато будет стараться удерживать прочитанные страницы в кэше.
Где это написано в описании этого флага?

S>Для приложений типа СУБД, которые используют свои механизмы кэширования, крайне рекомендуется использовать FILE_FLAG_NO_BUFFERING. Что, впрочем, тоже очевидно любому разработчику с толикой здравого смысла.
Разумеется. Но нюансы этого флага у них расписан приемлемо.

Здравствуйте, LaptevVV, Вы писали:

TL>>Конкретные примеры ЭВМ+ОС есть? Действительно просто интересно — не только ради спора.
LVV>БЭСМ6+любая ось на ней. ЕС(IBM|360-370)+оси на них. PDP-11+оси на них. И кстати, оси не падали за нефиг делать. Зато техника была значительно менее надежна.

ОСи там были на порядки проще, чем та же Vista или XP.
Работали на значительно менее разнообразном железе, нежели Vista/XP.
Программ под них — раз два и обчелся, а не миллионы как сейчас, причем разработанные как профессиональными программистами, так и теми кто прочитал книгу "стань программером за 21 час".
И задач они выполняли куда меньше, чем сейчас средняя XP/Vista.

Здравствуйте, Sheridan, Вы писали:

>> Поинтересуйся кто автор HTMLayout
S>Ох блин...
S>Бльшая работа. Хотя, к сожалению, я считаю что бесполезная.
Нет. HTMLayout — единственный нормальный тулкит, позволяющий красиво отделить создание интерфейса от создания кода. Интерфейс реально могут делать дизайнеры без программистов. На QT это нереально.

S>Имхо лучше бы сделать возможность применения css к нормальным (к обычным) элементам управления, как это сделано в кутэ4
Этого мало.

>> Нет, я не шароварщик (а что, собственно, в этом плохого?).
S>Да просто имхо скоро шароварщики отмирать начнут. По всему миру опенсорц широко шагает. Вон даже микрософт задумалось.
Шароварщики занимают свою нишу — небольшие дешовые программы, которые хорошо делают какую-то полезную и/или красивую фичу. Пока они никуда уходить не собираются. Да и не надо этого — чем больше разнообразия, тем лучше.

>> Но и мои приложения я открыть не могу, да и не хочу — это нафиг не нужно клиентам.
S>Насколько я помню — необязательно отрывать публично. Имхо достаточно софтину поставлять клиентам вместе с исходниками.
И чем это отличается от "открывать публично"?

>> Пишу на Java и C++, но с дорогими коммерческими библиотеками даже связываться не буду.
S>Да тебя никто и не заставляет.
Ну ты же предлагаешь QT...

Здравствуйте, Roman Odaisky, Вы писали:

RO>На самом деле, что один админ, что несколько, — не самая удачная система. Есть много администраторских действий, которые могли бы делать пользователи. Например, установить текстовый редактор. Это ведь не открывает никаких дыр в безопасности. Или подключить IP-адрес. Или еще что-нибудь.
Постепенно к этому идём. В следующем Ubuntu куча действий, типа изменения настроек сети как раз будет делаться через PolicyKit с fine-grained разрешениями.

Здравствуйте, CreatorCray, Вы писали:
CC>Где это написано в описании этого флага?
Это нигде не написано. Это мои догадки. Но я не понимаю, каким идиотом надо быть, чтобы открыть с этим флагом файл, и ожидать, что это улучшит характеристики последовательного чтения.

S>>Для приложений типа СУБД, которые используют свои механизмы кэширования, крайне рекомендуется использовать FILE_FLAG_NO_BUFFERING. Что, впрочем, тоже очевидно любому разработчику с толикой здравого смысла.
CC>Разумеется. Но нюансы этого флага у них расписан приемлемо.

Cyberax однажды (27 февраля 2008 [Среда] 04:28) писал:

> S>Бльшая работа. Хотя, к сожалению, я считаю что бесполезная.
> Нет. HTMLayout — единственный нормальный тулкит, позволяющий красиво отделить создание интерфейса от создания кода. Интерфейс реально могут делать дизайнеры без программистов. На
> QT это нереально.
При помощи css какраз реально. Причем расположение контролов будет дизайнеру недоступно, что хорошо.

> S>Имхо лучше бы сделать возможность применения css к нормальным (к обычным) элементам управления, как это сделано в кутэ4
> Этого мало.
Этого какраз вполне достаточно.

>>> Нет, я не шароварщик (а что, собственно, в этом плохого?).
> S>Да просто имхо скоро шароварщики отмирать начнут. По всему миру опенсорц широко шагает. Вон даже микрософт задумалось.
> Шароварщики занимают свою нишу — небольшие дешовые программы, которые хорошо делают какую-то полезную и/или красивую фичу. Пока они никуда уходить не собираются. Да и не надо
> этого — чем больше разнообразия, тем лучше.
Угу, полторы сотни всяких настройщиков системы — это хорошо
Лучше бы они в комманду собрались и написали что-ть для управления доменом.

>>> Но и мои приложения я открыть не могу, да и не хочу — это нафиг не нужно клиентам.
> S>Насколько я помню — необязательно отрывать публично. Имхо достаточно софтину поставлять клиентам вместе с исходниками.
> И чем это отличается от "открывать публично"?
Тем, что исходники _всем_ недоступны, и вполне можно продавать софт, не опасаясь потери денег.

>>> Пишу на Java и C++, но с дорогими коммерческими библиотеками даже связываться не буду.
> S>Да тебя никто и не заставляет.
> Ну ты же предлагаешь QT...
А ты прямо таки все бросаш и переходиш на кутэ

--
...belive in the matrix...

The Lex однажды (26 февраля 2008 [Вторник] 16:44) писал:

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

--
...belive in the matrix...

Здравствуйте, DKM_MSFT, Вы писали:

DKM>Сразу оговорюсь, что Винды я не компилировал, зато очень много компилировал Офис. Насколько мне известно, в Виндовс ситуация похожая. Так вот проблема состоит в том, что наличие исходных кодов это еще далеко не все. Тут существует очень сложная билд система, которая позволяет из этих исходников сделать относительно работоспособное приложение. Машина, на которой это все билдится, должна быть настроена очень специальным сложным образом. Для установки билд системы и настройки билд машин существуют утилиты, которые поддерживаются командой из сотни человек. Конфигурационные файлы этих утилит меняются десятки раз в день. В них безостановочно вносятся добавления и изменения. При этом даже здесь, люди, которые билдят офис чуть ли не ежедневно, регулярно сталкиваются с проблемами.

А F5 в студии нажимать не пробовали? Очень удобно. Или Ctrl+F5 если отладка не нужна?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, _d_m_, Вы писали:

___>>А про dinamyc link library (DLL) ты, судя по всему, ничего не слышал. Не надо "компилировать десятка два проектов".

RO>А тебе стоило бы услышать про import libraries. В тех же юниксах, чтобы связать программу с динамической библиотекой (.so) она должна присутствовать в системе, но никаких .lib не требуется. MS сделали так, что можно прилинковаться к DLL, не имея ее, но требуется .lib. У каждого подхода свои преимущества и недостатки; основная проблема подхода MS в том, что оне всё время «забывают» передать эти .lib юзеру (типа ненужны они ему).

Слышал про такое: "Не учи ученого — ..." ?

How To Create 32-bit Import Libraries Without .OBJs or Source

Здравствуйте, The Lex, Вы писали:

TL>Байку о "другом насквозь альтернативном HP'ном железе, которое не фига не x86" мы уже слышали — боян'с, батенька...

Как понять байку? здесь

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, CreatorCray, Вы писали:
CC>>Где это написано в описании этого флага?
S>Это нигде не написано. Это мои догадки.
Какова "надежность" этих догадок? Можно ли на них полагаться.

S>Но я не понимаю, каким идиотом надо быть, чтобы открыть с этим флагом файл, и ожидать, что это улучшит характеристики последовательного чтения.
Насчет последовательного думаю там чел очепятался. Файл базы данных далеко не всегда читается последовательно.

Добрался до сурсов — глянул краем глаза.
1) кэш манагер сам умеет опознавать последовательное чтение и включать с определенного момента read-ahead. Причем он опознает только последовательное чтение, т.е. никаких оптимизаций для распознанного рандомного не производится.
2) SEQUENTIAL_ONLY форсирует как минимум 2 read-ahead granularities (оффтопик по вопросу перевода терминов — фиг ведь это переведешь так, чтобы и кратко и всё понятно). При этом отключается автораспознавание.
3) при достижении конца файла со включенным SEQUENTIAL_ONLY можно опять начать читать с начала без потерь производительности — кэшманагер это предусматривает.
4) Если не указан ни SEQUENTIAL_ONLY ни RANDOM_ACCESS по умолчанию поведение файла как при последовательном чтении.
5) RANDOM_ACCESS отключает read-ahead.
6) если RANDOM_ACCESS не задан то используется более агрессивный способ очистки ненужных страниц кэша

Где то так.

Итого:
1) Смысл есть только в RANDOM_ACCESS флаге, да и то только при существенном кол-ве данных, которые будут повторно прочитаны в ближайшее время.
2) Выставление SEQUENTIAL_ONLY для файла, который действительно читается последовательно может ускорить чтение разве что за счет того, что код, распознающий тип чтения не выполняется (early out по флагу).

Здравствуйте, CreatorCray, Вы писали:
CC>Какова "надежность" этих догадок? Можно ли на них полагаться.
Нет, на них полагаться не надо. Надо полагаться на то, что если ты указываешь хинт и реальный паттерн доступа по большей части совпадает с хинтом, то производительность будет не хуже, чем без хинта. Возможно, будет лучше, чем без хинта.

S>>Но я не понимаю, каким идиотом надо быть, чтобы открыть с этим флагом файл, и ожидать, что это улучшит характеристики последовательного чтения.
CC>Насчет последовательного думаю там чел очепятался.
А я думаю, что нет. С тем же успехом можно полагать, что чел очепятался во всём остальном.

CC>Добрался до сурсов — глянул краем глаза.
CC>1) кэш манагер сам умеет опознавать последовательное чтение и включать с определенного момента read-ahead. Причем он опознает только последовательное чтение, т.е. никаких оптимизаций для распознанного рандомного не производится.
CC>2) SEQUENTIAL_ONLY форсирует как минимум 2 read-ahead granularities (оффтопик по вопросу перевода терминов — фиг ведь это переведешь так, чтобы и кратко и всё понятно). При этом отключается автораспознавание.
CC>3) при достижении конца файла со включенным SEQUENTIAL_ONLY можно опять начать читать с начала без потерь производительности — кэшманагер это предусматривает.
CC>4) Если не указан ни SEQUENTIAL_ONLY ни RANDOM_ACCESS по умолчанию поведение файла как при последовательном чтении.
CC>5) RANDOM_ACCESS отключает read-ahead.
CC>6) если RANDOM_ACCESS не задан то используется более агрессивный способ очистки ненужных страниц кэша

CC>Где то так.
Ну вот видишь — не слишком далеко от моих догадок. Причем я в сорсы не смотрел
CC>Итого:
CC>1) Смысл есть только в RANDOM_ACCESS флаге, да и то только при существенном кол-ве данных, которые будут повторно прочитаны в ближайшее время.
CC>2) Выставление SEQUENTIAL_ONLY для файла, который действительно читается последовательно может ускорить чтение разве что за счет того, что код, распознающий тип чтения не выполняется (early out по флагу).

Отлично. Осталось понять, сорцы какой именно винды изучались. А после этого понять, что эти "итого" можно выкинуть в топку для любой следующей версии или SP. А соображения, приведенные мной в начале постинга, останутся верными и в Windows 2015.

Здравствуйте, Sheridan, Вы писали:

S>Cyberax однажды (27 февраля 2008 [Среда] 04:28) писал:

>> S>Бльшая работа. Хотя, к сожалению, я считаю что бесполезная.
>> Нет. HTMLayout — единственный нормальный тулкит, позволяющий красиво отделить создание интерфейса от создания кода. Интерфейс реально могут делать дизайнеры без программистов. На
>> QT это нереально.
S>При помощи css какраз реально. Причем расположение контролов будет дизайнеру недоступно, что хорошо.

"расположение контролов будет дизайнеру недоступно, что хорошо."

А кому доступно тогда? Тебе? И что такое собственно дизайн в твоем представлении?
Проекты ты свои уже показал, давай, что-ли показывай свой UI тогда.

Или нет. Лучше не показывай.

c-smile однажды (27 февраля 2008 [Среда] 09:43) писал:

> "расположение контролов будет дизайнеру недоступно, что хорошо."
>
> А кому доступно тогда? Тебе? И что такое собственно дизайн в твоем представлении?
Дизайн это прежде всего цветовые решения и оформление вообще. Рвмочки, рюшечки итд.
Не стал бы я отдавать дизайнеру возможноть переставлять, добавлять и убирать контролы.

> Проекты ты свои уже показал, давай, что-ли показывай свой UI тогда.
> Или нет. Лучше не показывай.
А нечего.

--
...belive in the matrix...

Здравствуйте, Sinclair, Вы писали:

CC>>Где то так.
S>Ну вот видишь — не слишком далеко от моих догадок. Причем я в сорсы не смотрел
разница в том, что я в случае "посмотрел" — знаю а ты в случае "догадался" — всего лишь предполагаешь.

CC>>Итого:
CC>>1) Смысл есть только в RANDOM_ACCESS флаге, да и то только при существенном кол-ве данных, которые будут повторно прочитаны в ближайшее время.
CC>>2) Выставление SEQUENTIAL_ONLY для файла, который действительно читается последовательно может ускорить чтение разве что за счет того, что код, распознающий тип чтения не выполняется (early out по флагу).

S>Отлично. Осталось понять, сорцы какой именно винды изучались.
2000

S>А после этого понять, что эти "итого" можно выкинуть в топку для любой следующей версии или SP.
Вероятность этого достаточно мала, применительно к хинтам кэша.

Здравствуйте, Sheridan, Вы писали:

>> QT это нереально.
S>При помощи css какраз реально.
Угу. Т.е. максимум цвета поменять.

S>Причем расположение контролов будет дизайнеру недоступно, что хорошо.
Что в этом хорошего? В HTMLayout, например, мелкие правки GUI-багов (очепятки, размеры/положения контролов, порядок табов и т.п.) можно поручить дизайнерам-юзабилистам, не отвлекая на них программистов.

>> этого — чем больше разнообразия, тем лучше.
S>Угу, полторы сотни всяких настройщиков системы — это хорошо
Не только. Еще всякие скринсейверы (привет Xander Zerge!), игрушки, учёт рабочего времени и т.п.

S>Лучше бы они в комманду собрались и написали что-ть для управления доменом.
Каким доменом?

>> И чем это отличается от "открывать публично"?
S>Тем, что исходники _всем_ недоступны, и вполне можно продавать софт, не опасаясь потери денег.
Угу. А благодарные покупатели могут исходники (по этой же лицензии GPL!) выставить на своём сайте. А учитывая, что у нас есть конкурренты — они это сделают совершенно точно.

Здравствуйте, Sheridan, Вы писали:

>> Нет. HTMLayout — единственный нормальный тулкит, позволяющий красиво отделить создание интерфейса от создания кода. Интерфейс реально могут делать дизайнеры без программистов. На
>> QT это нереально.
S>При помощи css какраз реально. Причем расположение контролов будет дизайнеру недоступно, что хорошо.

Оффтоп, но имхо и по всему опыту — расположение контролов и вообще всего должно быть доступно _только_ дизайнеру — и это единственно _правильно_. И как раз CSS этим и занимается.

S>Угу, полторы сотни всяких настройщиков системы — это хорошо
S>Лучше бы они в комманду собрались и написали что-ть для управления доменом.

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

>> S>Насколько я помню — необязательно отрывать публично. Имхо достаточно софтину поставлять клиентам вместе с исходниками.
>> И чем это отличается от "открывать публично"?
S>Тем, что исходники _всем_ недоступны, и вполне можно продавать софт, не опасаясь потери денег.

Ага. И называется это "секрет Полишинеля" (к)
Делать исходники "доступными избранным" практически возможно для заказных разработок, когда заказчик и пользователь системы выступает же и коде-овнером — и тогда трава не расти что он там со _своими_ уже исходниками будет делать. А если открыть одному пользователю — обязательно найдется хоть кто-нибуть, кто сделает "для всех". Это мы уже проходили на чем угодно что можно открыть или не открыть...

Здравствуйте, CreatorCray, Вы писали:
CC>разница в том, что я в случае "посмотрел" — знаю а ты в случае "догадался" — всего лишь предполагаешь.
Вот именно. В результате, твоя способность писать корректный код зависит от наличия исходников, а моя — нет.

S>>Отлично. Осталось понять, сорцы какой именно винды изучались.
CC>2000

S>>А после этого понять, что эти "итого" можно выкинуть в топку для любой следующей версии или SP.
CC>Вероятность этого достаточно мала, применительно к хинтам кэша.
Не смеши меня. Как раз такие нюансы, как поведение кэша, переписываются очень часто. Особенно это касается использования флагов, введенных для forward compatibility.
При случае взгляни на исходники, к примеру, 2k3 или Longhorn — проверим, справедливы ли эти мои догадки.

З.Ы. Я до сих пор не понимаю, что нового тебе дало это исследование по сравнению с MSDN.