-
Perturbation: Май 2007
@import url('http://www.blogger.com/css/blog_controls.css');
@import url('http://www.blogger.com/dyn-css/authorization.css?targetBlogID=5081823616705531487');
#navbar-iframe { display:block }
skip to main |
skip to sidebar
Perturbation
31 Май 2007 г.
Google+Параллелизм: экспансия продолжается
2 дня назад на Thinking Parallel появилась занятная статья - "How Much of the Industry Will Go Parallel?" - "Насколько параллелизм востребован IT-индустрией сегодня ?", в которой Michael Suess высказывает свои предположения по этому поводу. Нужно сказать, что Michael Suess вообще достаточно интересная личность, и с точки зрения параллельного программирования тоже ;) (особенно мне ценен его цикл интервью, ru: здесь и здесь). Дак вот Михаил считает, что параллельное программирование будет интересно прежде всего двум группам разработчиков. К первой группе относятся те, кто вечно борется с нехваткой ресурсов и производительности - это все возможные разработчики игр, систем моделирования, систем обработки сигналов и информации. Ко второй же ещё более малочисленной на сегодняшний день группе относятся разработчики, которые захотят использовать многоядерный параллелизм для придания своим приложениям большей интерактивности и других(не известных на сегодняшний день) преимуществ и фишек. Среди прочих Михаил приводит такой пример - вы ведете конференцию по ICQ\Skype, а параллельно с этим сторонняя утилита распознает некоторые ключевые слова в вашем диалоге и подыскивает информацию, которая может потенциально вас заинтересовать... скажем вы часто говорите про параллельное программирование - вот вам свежая подборка с тематических новостных сайтов и блогов, обсуждаете девушек - вот вам... ну вообще додумаете сами).И все бы, как говориться, ничего, но вот только сегодня получаю подтверждение, что параллелизмом интересуются не только ресурсо-фобы(первая группа), но и Google. Новое приложение этой компании можно смело отнести к каркасу, который призван поддерживать вторую группу "параллельных разработчиков". Новый продукт называется Google Gears и призван помочь разработчикам в создании нового(в какой-то степени) класса приложений - offline-online application. Эти приложения работают в рамках браузера, но при этом для их работы не обязательно требуется доступ в интернет (т.е. для выполнения некоторых функций им может быть нужен доступ в сеть, но вообще они могут работать и без него). Краткое описание этой новинки от Google находиться здесь. И так, этот библиотечный каркас включает в себя:Локальный сервер - используется для кэширования и обслуживания ресурсов, которые нужны приложению для работы (HTML, JavaScript, рисунки, видео и т.д.). Приложение получит доступ к ним локально, если доступ к удаленному серверу отсутствует.БД - для хранения всего этого дела и прочей информации приложенияи самое интересное Пул процессов(worker thread pool). Концепция пула процессов далеко не нова - это некоторое хранилище процессов, которые выделяются по требованию приложения. Дак вот Google встроил такой пул в свой каркас, как раз для того чтобы упростить разработку интерактивных (т.н. насыщенных параллелизмом) приложений. Полное описание worker thread pool API находится здесь. Вкратце скажу, что процессы, которые выделяются из пула, могут взаимодействовать только через посылку сообщений. Сообщения представляют собой строки, если нужно передать не строку, требуется предварительная "сериализация". Отдельно отмечу, что в пуле хранятся не потоки операционной системы, а т.н. легковесные процессы, что в сочетании с использованием сообщений для взаимодействия таких процессов делают всю систему похожей на Erlang-овские системы.Такие дела, да чуть не забыл, все это великолепие за лицензировано как Open Source.
Автор
Didro
на
10:42
0
комментария(ев)
Ярлыки:
Concurrent,
Google,
Parallel
Плоский MS
MS разработал новый тип пользовательского интерфейса для PC - стол, на крышке которого размещен здоровенный тачскрин (сенсорный экран). Называется это чудо инженерной мысли - Surface (Поверхность\Плоскость) Наблюдаются следующие отличия от стандартных интерфейсов, основанных на тачскринах:Экран Surface способен распознавать несколько одновременных нажатий (можно работать обоими руками)Большой размер Surface и его горизонтальное расположение позволяют работать сразу нескольким пользователям одновременноSurface способен узнавать ранее запомненные предметы, которые положили на поверхность экрана и совершать при их возникновении предопределенные действия. Так, например, компания T-Mobile, уже заказавшая несколько Surface предполагает расположить их в сети своих магазинов. Покупатель сможет подойти к стойке с Surface и когда он положит на неё свой мобильник, Surface по коду мобильника распознает марку и модель телефона и отобразит на экране совместимые с этим телефоном "прошивки", игры, рингтоны и пр. Затем пользователь ухватившись за одно из изображений этих продуктов перетащит их на свой телефон и продукт будет "перелит" в телефон, скажем, по WiFi.Источник - incideHPC
Автор
Didro
на
1:33
1 комментария(ев)
Ярлыки:
Gadgets,
MS
Безопасность Vista
Известный центр тестирования CRN Test Center провел ряд испытаний системы безопасности новой операционной системы MS Vista, по результатам которых было заявлено, что система безопасности Vista ничуть не лучше аналогичной в XP. Грубо говоря те известные дыры, которые были в XP, благополучно по наследству перешли в Vista.Обзорная статья - здесь.Слайды иллюстрирующие тестирование - здесь.Источник - EETimes
Автор
Didro
на
1:10
0
комментария(ев)
Ярлыки:
MS,
Vista
30 Май 2007 г.
SSE из управляемого кода
Ещё с 90х годов процессоры Intel и AMD поддерживают в некоторой степени SIMD параллелизм в форме MMX и SSE. Несмотря на то, что большинство наших программ ориентированы на MIMD вычисления, исследования SIMD параллелизма ведутся ещё с начала 80 х. Вообще это направление выглядит весьма перспективным, хотя и не настолько разрекламированным как многоядерные процессоры. В частности идеи векторизации весьма популярны среди суперкомпьютерного сообщества и сообщества FORTRAN программистов. Интерес к этой теме подогревается также GPGPU сообществом (см., например, здесь и здесь), что в сочетании с многоядерной чехардой, дает интересную почву для размышлений.Сегодня мы можем использовать SSE из управляемого кода, при этом правда требуется некоторая ловкость рук и интероп, который нехило уменьшает производительность. Вот простой пример – перемножение двух массивов.Поскольку мы не можем прямо исползовать SEE инструкции в управляемом коде, нам придется вначале создать небольшую DLL. Назовем её “vecthelp.dll” и экспортнем из неё всего одну функцию:#include const int c_vectorStride = 4;extern "C" __declspec(dllexport)void VectMult(float * src1, float * src2, float * dest, int length) { for (int i = 0; i < length; i += c_vectorStride) { // Vector load, multiply, store. __m128 v1 = _mm_load_ps(src1 + i); // MOVAPS __m128 v2 = _mm_load_ps(src2 + i); // MOVAPS __m128 vresult = _mm_mul_ps(v1, v2); // MULPS _mm_store_ps(dest + i, vresult); // MOVAPS }}“VectMult” принимает два указателя на массивы float-ов – “src1” и “src2” – каждый из которых имеет размер “length” и затем сохраняет результат их перемножения в массив “dest”. Обратите внимание мы перемещаемся по массиву с шагом 4 (c_vectorStride = 4). На каждой итерации мы загружаем 4 смежных элемента массивов “src1” и “src2” в XMMx регистры. Именно это делают SSE-инструкции “_mm_load_ps” . Затем с помощью “_mm_mul_ps” мы перемножаем эти 4 элемента параллельно. После этого результат сохраняется в массиве “dest”. Предполагается, что длина массивов кратна 4.Теперь чтобы использовать этот параллельный умножитель из управляемого кода мы вынуждены использовать P/Invoke. Да при этом ещё нельзя забывать о том, что SSE работает с 16 байтным выравниванием(alignment), поэтому нам придется немного поколдовать, чтобы заставить CLR выдать нам его. Я размещают массив в стэке, чтобы не делать pinning массива(запрет на автоматическое перемещение переменной в памяти, без пиннинга сборщик мусора при устранении фрагментации памяти может произвольно менять адрес переменной, разумеется он автоматически перенастраивает все ссылки на новое местоположение переменной, но при интеропе это не допустимо и нужно либо делать пиннинг, либо размещать переменную в стэке). При больших массивах правда может возникнуть переполнение стэка. Короче это просто пример:using System;unsafe class Program { [System.Runtime.InteropServices.DllImport("vecthelp.dll")] private extern static void VectMult(float * src1, float * src2, float * dest, int length); public static void Main() { const int vecsize = 1024 * 16; // 16KB of floats. float* a = stackalloc float[vecsize + (16 / sizeof(float)) -1]; float* b = stackalloc float[vecsize + (16 / sizeof(float)) -1]; float* c = stackalloc float[vecsize + (16 / sizeof(float)) -1]; // To use SSE, we must ensure 16 byte alignment. a = (float *)AlignUp(a, 16); b = (float *)AlignUp(b, 16); c = (float *)AlignUp(c, 16); // Initialize 'a' and 'b': for (int i = 0; i < vecsize; i++) { a[i] = i; b[i] = vecsize - i; } // Now perform the multiplication. VectMult(a, b, c, vecsize); ... do something with c ... } private static void * AlignUp(void * p, ulong alignBytes) { ulong addr = (ulong)p; ulong newAddr = (addr + alignBytes - 1) & ~(alignBytes - 1); return (void *)newAddr; }}Хотелось бы конечно, чтобы при этом результирующая производительность возросла в 4 раза. К сожалению P/Invoke делает свое черное дело и прирост производительности будет заметен только на больших массивах. Интересно многим ли из вас нужно вычислять произведение 16MB массивов. Кто-то безусловно занимается этим, но не думаю, что таких людей много. Однако даже за вычетом издержек на P\Invoke в итоге мы получаем 2 кратный прирост производительности на небольших массивах, 3х кратное увеличение на массивах большого размера.Очевидно, что в будущем поддержка векторных операций в процессорах будет только расти и следовательно эти цифры изменяться в большую сторону. Возможно, даже когда-нибудь мы сможем пользоваться SSE, не прибегая к интеропу. Представьте – на 32х ядерной машине, если на каждом ядре будет стоять 16-ти позиционное векторное АЛУ, то мы в итоге получим 32х16 (512) потенциал для параллельного исполнения кода…, конечно, если мы сможем разбить нашу задачу на 512 независимых подзадач. Популярность GPU отчасти обусловлена более «широким» АЛУ, которыми они снабжены. Может быть как-нибудь я расскажу как можно сложить два массива параллельно с использованием пиксельных шейдеров и DirectX.(с)Джо Даффи. Перевод мой.Источник - Блог Джо Даффи (Joe Duffy)
Автор
Didro
на
13:53
0
комментария(ев)
Ярлыки:
.NET,
C#,
Concurrent,
Parallel
Вторая жизнь Интел
Некоторое время назад MS открыла остров под названием “Visual Studio island” в онлайн-игре Second Life. На острове было несколько занимательных головоломок и прочее... Корпорация Intel видимо решила не уступать софтверному гиганту и также открыла собственное представительство в Second Life. В частности вчера проходила виртуальная конференция - ISN Lunch on Second Life, о чем незамедлительно известили блоггеры из Intel Software Network. Скриншот этой конференции вы можете видеть слева, а видео доступно на этой страничке.Источник - ISN
Автор
Didro
на
3:44
0
комментария(ев)
Ярлыки:
Intel,
Web
26 Май 2007 г.
Лед тронулся…?
Производитель процессоров больше не может ждать, когда мы – программисты начнем разрабатывать параллельный софт, для того чтобы многоядерные процессоры стали по настаящему востребованными. Об этой тенденции говорил Эдвард Ли (университет Беркли) в своей статье «Проблемы с потоками»: “Интересно, что сами производители процессоров ратуют за многопоточное программирование, стараясь всячески продвинуть его в программистские массы. Их действия обусловлены тем, что с их точки зрения многопоточное программирование позволит использовать параллелизм (многоядерность), который они собираются продавать. Так, например, Intel проводит активную компанию по поддержке обучения студентов многопоточному программированию. Если эта компания будет иметь успех, то следующее поколение программистов будет ещё более рьяно использовать потоки, что приведет к ещё более удручающим последствиям.”Замечу, что Intel уже достаточно давно обращает внимание на продвижение идей параллелизма (и инструментов их поддерживающих) в программистские массы. Однако, будучи участником одного из таких семинаров (СПб, окт.2006) я не заметил каких-либо действительно современных предложений от Intel по решению проблем параллельного ПО. Оговорюсь, что под «действительно современными предложениями» я имею в виду то, о чем кажется, говорят все вокруг - более выразительные средства управления параллелизмом. На семинаре же Intel говорил об использовании OpenMP, о программировании на уровне мониторов\блокировок и о поддержке многопоточного программирования в .NET. Поэтому эта новостная заметка на EETimes привлекла мое внимание:Интервью с главой лаборатории Intel по разработке микропроцессоров в Хиллсборо (Оригон, США) – Шекхар Боркар (Shekhar Y. Borkar).Сегодня с развитием многоядерных процессоров должность разработчика параллельного ПО становится самой востребованной в Intel’овских исследовательских лабораториях по разработке микропроцессоров. Команда, численностью 250 человек, постоянно занимается разработкой прототипов DSL-ей(domain-specific languages) для описания параллелизма, а также параллельных версий существующих языков и приложений.«В прошлом программы все работали быстрее и быстрее с увеличением частоты процессора, однако сегодня все изменилось – у нас больше не получиться получить прирост производительности «за так», халява кончилась - говорит Шекхар Боркар - Разработка параллельного ПО и распространение идей параллелизма в индустрии - «вот основная цель моей исследовательской группы. Очевидно, что параллельность ПО будет «удваиваться» каждые два года (или что-то около этого) – согласно закону Мура». 200 из 250 разработчиков лаборатории Боркара занимаются проблемами параллельного программирования. «К примеру сейчас - говорит Боркар - мы занимаемся проблемой внедрения языковых конструкций, описывающих параллелизм по данным, в интерпретируемые языки, такие как Ruby».Наиболее перспективной областью исследований, по мнению Боркара, являются DSL-и – небольшие специализированные языки, предназначенные для описания параллелизма в таких областях как компьютерная графика, сетевые приложения, разработка отладчиков и библиотек. К примеру, Intel сейчас занимается разработкой нового языка описания сетевых (TCP\IP) взаимодействий в «более параллельном» стиле.Компания также ведет разработку прототипов приложений в таких областях как распознавание и рендеринг в реальном времени. Считается, что поиск параллельных решения этих прикладных задач наиболее прост (тривиален). «Все, что вы делаете при распознавании или рендеринге в играх, так это работаете с матрицами – но параллельная обработка матриц хорошо известна нам ещё со времен суперкомпьютеров» - говорит Боркар, проработавший несколько лет в суперкомпьютерном подразделении Intel, сегодня уже почившим в бозе.В ходе нашей беседы Шекхар не раз говорил о том, что считает, что разработчики всех уровней (от архитектора ПО – до кодера) должны обратить своё внимание на проблемы параллелизма: «Вокруг наших программ колышутся обширные поля параллелизма, жаждущие начала хорошей жатвы. Мы сейчас во многом выступаем в качестве проповедников параллелизма для индустрии и университетов. Однако мы понимаем, что такие координальные изменения требуют времени – около года или двух».Сегодня такие университеты как Беркли, Стэнфорд, MIT, Иллинойский университет хорошо понимают необходимость обучения своих студентов и бакалавров технологиям параллельной разработки. «Изменение индустрии ПО происходит уже сейчас» - считает Шекхар Боркар.Источник – EETimes
Автор
Didro
на
0:44
0
комментария(ев)
Ярлыки:
Concurrent,
Intel,
Parallel
25 Май 2007 г.
Параллельное программирование. Что делать?
Автор - Joseph Landman(с) | scalability.orgПеревод - Петров Александр(с)Ранее мы уже обсуждали некоторые аспекты будущего параллельного программирования и современных тенденций в области. Грубо говоря, на сегодняшний день мы можем выделить два типа параллельных систем и инструментов их создания – системы с разделяемой (общей) памятью и системы с распределенной памятью. Наиболее известными инструментами создания таких систем являются OpenMP и MPI, соответственно. Впрочем есть и другие типы систем, и соответственно другие инструменты, но наиболее широко распространены именно эти.Проблемы?Используя OpenMP, вы по сути дела снабжаете свой код некоторыми пометками, которые позволяют компилятору «развернуть» эти пометки в недостающий код. Т.е., другими словами, OpenMP является макрорасширением языка (языком в языке) – компилятор выполняет автоматическое распараллеливания вашего алгоритма, руководствуясь вашими пометками (иногда это вызывает интересные проблемы - пример). Однако OpenMP предполагает, что вы программируете систему с разделяемой памятью – OpenMP не способна генерировать код, предназначенный для распределенного исполнения. Используя MPI, вы полновластно владеете своим кодом. Вы – а не компилятор выполняете основную работу, используя библиотечные функции MPI. Компилятор не способен оптимизировать (в плане параллелизма) ваш mpi-код, поскольку это всего лишь вызовы функций. Ещё хуже, что вы по сути дела находитесь в свободном плавании и вольны выбирать тот способ решения задачи, какой вам заблагорассудиться, понятно, что этот способ вовсе не обязательно будет лучшим или вообще правильным. Раньше я уже говорил, о том, что нам следует пересмотреть те инструменты, языки, которые мы используем для параллельного программирования. Дело не в том будет ли программист сам писать весь код или отдаст часть задач на откуп компилятору – вопрос не в предоставлении программисту большей или меньшей степени контроля над кодом, вопрос в том, что нам нужны более выразительные средства управления параллелизмом.Я вовсе не хочу сказать, что OpenMP – это плохо. Мне нравиться OpenMP, но мы не сможем использовать OpenMP в распределенных системах (а именно за ними будущее высокопроизводительных вычислений). Я не хочу сказать, что MPI – это плохо, просто MPI – это довольно-таки низкоуровневый инструмент, используя, MPI вам приходиться явно прописывать все то, что обычно генерирует за нас сам компилятор. MPI – это что-то вроде ассемблера в параллельном программировании. Поэтому используя его, нужно быть готовым к тому, что совсем не просто написать рабочий код, неп росто его отлаживать, не просто его оптимизировать. Большинство программ MPI-программистов дают лишь 10-15% прирост производительности при увеличении числа ядер. Очень редко эта цифра достигает 50+%. Проблема не в программистах (а вы как думали?!) – проблема в том, что при распараллелировании крайне тяжело выделить действительно продолжительные по времени исполнения куски кода. Другой вопрос, который заинтересовал меня, когда я размышлял о файловых системах и прочих хранилищах информации – это концепция локальности. Сегодня большинство MPI программ написаны так, словно распределенное взаимодействие происходит без задержек (моделирование и учет задержек эт.вообще большая проблема как в аппаратуре, так и в софте– вот, имхо, интересный пример) Сегодня мы как бы считаем, что все узлы нашей системы расположены локально – и в этом смысле, мы не учитываем задержки внутри нашей системы (или считаем величину этих задержек одинаковой и постоянной). Понятно, что такие упрощения не учитывают некоторых важных вещей. Окружающий нас мир не обладает локальностью. Наши алгоритмы, которые в определенной степени, являются отражением действительности с помощью некоторых математических конструкций, должны учитывать отсутствие локальности. Так мы можем воспринимать неравнозначность узлов сети как отсутствие локальности и учитывать это в наших алгоритмах. Однако, это опять же приводит нас к излишней низкоуровневости (к копошению) – не должен ли сам компилятор заботиться об отсутствии локальности? Если бы мы смогли научить наши компьютеры учитывать характер распреденности в системе, то это, возможно, помогло бы нам сделать параллельные программы более предсказуемыми и надежными, хотя конечно, это сказалось бы на времени компиляции и на сложности компиляторов. Одним словом, нам стоит задуматься о программировании систем, учитывающих отсутсвие локальности. Систем, в которых начинают играть роль такие понятия как доступность ресурсов во времени. Систем, в которых даже привычная файловая система предстает перед нами в другом свете – к примеру, в таких системах нам может потребоваться описать и реализовать единую модель доступа к файловой подсистеме из любой точки нашей системы. Возможно, это является чрезмерным усложнением на сегодняшний день, но я считаю, что, по крайней мере, мы должны учитывать распределенность и "нелокальность" как часть парадигмы программирования.Программирование масштабных многопроцессорных систем будет только усложняться с ростом их масштаба. К тому же очевидно в скором времени появиться не-SMP системы (aSMP - асимметричные многопроцессорные системы), а также системы, использующие дополнительные сопроцессоры (называемые также акселераторами или APU (accelerator processing units)). Любая из этих нелокальных систем потребует четкого представления принципов распределенного (как в пространстве, так и во времени) доступа к данным. Надеюсь мы сможем преодолеть господствующие сегодня стереотипы и найти простые способы решения этих непростых проблем.Честно говоря, я, например, уже знаю даже название гипотетического языка, который будет работать в таких распределенных системах.Это Фортран.Joseph Landman(с).Данная заметка показалась мне интересной, поскольку она более-менее отражает сегодняшние стремления параллельных программистов (нет не стремление программировать на Фортране, а необходимость создания более выразительных инструментов) в интересном свете распределенных систем. Реальными примерами систем, о которых говорит автор, являются Googl-овская MapReduce и системы на основе идей GPGPU (General-Purpose computation on graphics processing units (GPUs)).MapReduce - сильно распределенная система – это кластер из 1800 узлов (в каждом по 2 Intel Xeon 2GHz), между которыми распределяются данные и задания. При таком количестве узлов одной их основных проблем кластера является его отказоустойчивость – в том, смысле, что при выходе одного узла система должна перенаправить его данные и его задания другому узлу и т.д. Система называется MapReduce – поскольку модель этой системы основана на использовании двух широко распространенных в функциональном программировании функций: Map (отображение одного множества в другое путем применения функции преобразования к элементам исходного множества) и Reduce (получение агрегированной характеристики элементов множества (нпр. их суммы)).GPGPU cистемы принадлежат к другому классу систем, которые автор, называет APU-системы. В таких системах (аппаратно-программных комплексах, по сути) центральному процессору аккомпанирует целый ряд внешних, обычно специализированных вычислителей. Это могут быть как ПЛИСы, так и микроконтроллеры или специализированные микропроцессоры (нпр. сигнальные(DSP) процессоры). Очевидно, что такие системы прямо-таки насыщены параллелизмом (вычислителей-то много) и они не являются однородными (в отличие, скажем, от сегодняшних многоядреных процессоров). Они не являются однородными поскольку в них могут использоваться различные каналы связи между элементами системы, что влечет отсутствие локальности, о которой говорит автор. В GPGPU системах, в качестве специализированного вычислителя выступает процессор видео карточки.
Автор
Didro
на
14:47
3
комментария(ев)
Ярлыки:
Concurrent,
Google,
GPGPU,
Modelling,
Parallel
Google Hot Trends
Чуть больше года после запуска Google сервиса Google Trends, 22 мая компания представила вниманию общественности новый инструмент анализа общественного мнения, основных тенденций и трендов. Новый сервис называется Google Hot Trends и в некотором смысле дополняет Google Trends. Google Hot Trends анализирует поток поисковых запросов к Google Search, Google News и Google Blog Search и составляет отчет о наиболее частых\популярных запросах. Основным отличием Google Hot Trends от Google Zeitgeist будет оперативность Hot Trends. В своем блоге Google утверждает, что данные Google Hot Trends будут обновляться несколько раз в день, тогда как Google Zeitgeist («дух времени») предоставляет лишь еженедельные, ежемесячные и ежегодные отчеты. Представляется, что сочетание Google Zeitgeist и Google Hot Trends будет особо плодотворным.Источник – Quick Online Tips
Автор
Didro
на
10:26
0
комментария(ев)
Ярлыки:
Google
Intel Mobile Metro Notebook - Тонкий ноутбук
Недавно Intel анонсировал прототип интересного ноутбука. Толщина этого чуда составит всего 1.7 см., а вес - 1 килограмм. (свешайте мне 2 кило ноутбуков, пожалуйста :). С задней стороны экрана размещается ещё один небольшой экранчик. Приятная вещица, вообщем, полюбоваться на неё можно на этом сайте или на картинках ниже (Для увеличения - нажмите на картинку).Источник - Intel Software Blogs
Автор
Didro
на
9:32
0
комментария(ев)
Ярлыки:
Gadgets,
Hardware
24 Май 2007 г.
Microsoft vs Free World | Microsoft будет хорошим
В продолжение истории с патентами...Вчера, на все той же конференции Interop 2007 Боб Маглиа (Bob Muglia) вице-президент MS, отвечающий за корпоративное направление компании, заявил, что "патентные претензии к Open Source сообществу" не стоит рассматривать как "объявление войны MS и Open Source". Напротив Маглиа заявил, что ключевой посылкой всех действий компании является направление на интеграцию продуктов MS и продуктов других производителей, в том числе, входящих в Open Source сообщество. Компания понимает, что продукты MS должны просто и удобно интегрироваться в корпоративной среде предприятия. Лицензионная политика компании является, прежде всего, ответом на запросы клиентов, которые, по словам вице-президента MS, хотят быть уверенными, что, используя тот или иной продукт, они не смогут стать жертвой чьих-то патентных претензий. Маглиа заявил, что подчас клиенты MS заявляют о своей неприяз
shimadzu
knauf
7-450
li-da
.
5440.11 ()
inerta
revol
5004.10 ()
2112
de luxe 5040.11
russia music awards
kiev apartments service
, ,
ziplock
fifa 2006
8800 white gold
-