IT в России и мире в реалиях мирового кризиса
1,404,650 8,482
 

  Спокойный ( Слушатель )
12 ноя 2010 03:58:21

Тред №273610

новая дискуссия Дискуссия  394

Президиум совета при президенте РФ по развитию информационного общества

в целом одобрил идею создания
национальной программной платформы.
В документе говорится, что НПП необходимо создавать
на базе имеющихся разработок в области свободного программного обеспечения,
а также с использованием облачных вычислений.
При этом рассматриваются два наиболее вероятных сценария создания НПП.
Первый заключается в разработке национальной операционной системы
и ограниченного набора приложений для работы государственных органов.
Второй представляет собой разработку в первую очередь
единой системы требований к общесистемному и прикладному
программному обеспечению, которое распространяется под свободной лицензией,
для использования в госучреждениях.
В этом случае требуется также создать единое общедоступное хранилище
этих программ.
При этом первый вариант признается наименее приемлемым,
так как при создании национальной операционной системы
возникает опасность появления монополии.
При условии успешной реализации внедрения НПП доля
национальной операционной системы на российском рынке - без учета госорганов,
составит не менее 2% к 2012 году и не менее 5% — к 2013-му.
  • +0.00 / 0
  • АУ
ОТВЕТЫ (29)
 
 
  ata ( Слушатель )
13 ноя 2010 15:04:43


Эхх...(достает шашку)
Интересно, а про облачные вычисления они зачем вставили? Типа услышали модное слово в телевизоре? Или под Линухом уже есть нормальные опенсорсные инфраструктурные решения production-grade?

Нет, конечно, если бы Россия в рамках этого проекта спонсировала или хотя бы допиливала опенсорсные проекты для того, чтобы их можно было внедрять на предприятии без битья головой об стену (да вообще... хотя бы просто внедрять) - это было бы здорово. Но вот червь сомнения гложет меня...
  • +0.00 / 0
  • АУ
 
 
  Schreibikus ( Слушатель )
19 ноя 2010 15:01:28


Дык это Сергей Белоусов (Parallels) Димону по ушам проехал.
Это не шутка, кстати.
  • +0.00 / 0
  • АУ
 
  Поверонов ( Слушатель )
13 ноя 2010 17:31:07


О, в совете ГА читают  ;):



Придётся обсудить, почему пора проектировать новую ОСь для серверных кластеров.
Как уже упоминалось выше и Unix=Linux и вслед за ними Windows задумывались как многопользовательские=многотерминальные системы. Отсюда - примитивное разделение полномочий между рутом и юзерями, и детский уровень системной безопасности. Конечно в те далекие годы пользователями были лишь научные работники - одуванчики, а единственным хакером в округе был сам рут. О системной безопасности представления были вообще на примитивном уровне разделения доступа к файлам. Все ресурсы - колхозные, сколько кто сможет, столько и возьмет. Позднее кое-что в Линукс донавесили как-то selinux, квотирование дискового пространства, но этого совершенно недостаточно для организации гарантированно безопасных ( друг для друга ) "вечно" ( 24x7 ) работающих сервисов.
Новая ОСь должна обеспечивать не  многотерминальное многопользовательское обслуживание, когда основным источником событий являлся палец на клавиатуре, а набор "вечноживых" многонитевых сервисов. Что это меняет ?
Во-первых, отменяется напрочь такая категория как пользователь. Нечего ему делать на серверах, кроме как коннектиться к сервисам со своего "клиента".
Во-вторых, рут расщепляется по меньшей мере на три категории администраторов:
а) администратор безопасности, который только имеет право определять права всех других администраторов и имеет доступ к соответствующим ключам.
б) системный администратор, который только имеет право распределения общих системных ресурсов между сервисами. ( Каждый сервис обязан довольствоваться отведенной ему квотой памяти, дискового пространства, сетевого траффика и т.д. и т.п.)
в) администратор сервиса, который должен иметь все права на установку и конфигурирование своего сервиса в пределах установленных для сервиса квот.
Причём полномочия между администраторами должны быть разделены так строго, чтобы нижестоящий администратор никоим образом не мог бы влезть в сферу вышестоящего, в то же время имея все возможности выполнения собственных функций в отсутствии других администраторов.

Каждый сервис должен выполнять свои функции, оставаясь строго в рамках своей "песочницы" и никак не залезая на квоты других сервисов. Никаких разделяемых ресурсов, кроме ОС. Единственным способом коммуникации между сервисами должны оставаться "сообщения", транспортируемые друг другу через операционную систему. Никакой общей памяти. Каждый сервис должен функционировать в своей квоте оперативной памяти и уметь "виртуализировать" память самостоятельно через собственный map-файл и/или собственную область подкачки. Очевидно, что ОСь также должна быть способна оставаться в отведенных ей рамках памяти. Только при подобных жёстких ограничениях мыслимо организовать надежную работу серверных кластеров. Понятно, что нынешние ОСи для этого пока слабо годятся.
Чем-то это напоминает уже забываемые ОС реального времени типа RSX. А так же виртуальные машины.
Но это же варварство гонять виртуальные машины только для изоляции сервисов.
Как-то вот так. Пусть IT-общественность добавит, что сможет.
  • +0.00 / 0
  • АУ
 
 
  bjaka_max ( Слушатель )
13 ноя 2010 20:11:04

А почему собственно? Виртуализация сейчас вообще аппаратная. Вполне как раз вашу схему можно реализовать в Xen. А XCP так и вовсе для облаков предназначен. OpenVZ опять же посмотрите, там виртуализуется не вся машина.

Ну а так... если остаться в рамках одной операционки, то chroot, acl и сокеты никто не отменял. А квоты... это ерунду вы какую-то говорите... Что по вашему должно делать приложение исчерпавшее свою квоту оперативки? Учтите, приложение памяти не набирает "просто так", если память выделяется, то она приложению нужна для работы (ну в идеале конечно).
  • +0.00 / 0
  • АУ
 
 
 
  Поверонов ( Слушатель )
14 ноя 2010 01:08:17

Ну, так и должно вытолкнуть все другие сервисы в своп и потом зависнуть в коротком цикле в ожидании  от них ответов  :D. Как это обычно происходит у очень нужных приложений в отношении ненужных, но зачем-то болтающихся на том же сервере.
  • +0.00 / 0
  • АУ
 
 
 
 
  bjaka_max ( Слушатель )
14 ноя 2010 08:46:50

А в вашем варианте это приложение просто упадёт. И все остальные сервисы от него ответ будут ждать. Даже если в системе дохрена оперативы свободной, которую остальные сервисы не использовали.
  • +0.00 / 0
  • АУ
 
 
 
 
 
  Поверонов ( Слушатель )
14 ноя 2010 15:12:43

Повторюсь для невнимательных:


Кстати подобное уже приходило в чьи-то светлые головы:

Цитата: Valery
И ограничение на колличество ожиданий операций ввода-вывода там было реализовано еще в 70-х.
Равно, как и квоты на виртуальное адресное пространство, занимаемое место в своп-файле и т.д.

  • +0.00 / 0
  • АУ
 
 
 
 
 
 
  basilevs ( Слушатель )
15 ноя 2010 17:35:38


Вообще-то у этого "подобного" даже название своё было: IBM OS/VM.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
  bjaka_max ( Слушатель )
16 ноя 2010 15:06:27

Вы лучше объясните зачем это может вдруг понадобиться? И почему этот геморой с отдельным свопом на каждый процесс будет лучше чем сейчас? Между прочим доступ к диску это тоже ресурс. И если приложение (при свободной оперативе, которую другие приложения не использовали) забъёт канал доступа к диску, играя со своим свопом, то вся система встанет колом.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
  Поверонов ( Слушатель )
16 ноя 2010 23:40:57

Вы сами назвали Вам ответ : чтобы один неточно сконфигурированный сервис не мог "поставить колом всю систему", перетянув на себя какой-нибудь из ресурсов. Если своп общий, его может до конца "забить" какой-нибудь один жадный процесс. При квотированном свопе такой процесс в худшем случае лишь только сам остановится.
Насчет доступа не думаю, что возможно забить очередь io-операций так,что в нее больше никому не протиснуться. Всё-таки все современные серверы должны иметь внутренний или внешний аппаратный RAID контроллер, который сам организует и кэш блоков обмена и очередь операций.
И вообще трудно представить, как можно перехватить канал доступа, так что в него никто больше не втиснется, всё таки io имеют самые большие таймауты, разве что задать цикл асинхронных io-операций.
Это наверное можно предупредить на уровне ОС, поддерживая круговую дисциплину обращения процессов к каналам io.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
  bjaka_max ( Слушатель )
16 ноя 2010 23:58:52

Ну у нас вот например на ресурсе куча мелких файлов и клиенты постоянно обращаются к разным, при нашей пиковой нагрузке файловая подсистема практически сдыхала, сильно увеличивалось время отклика сервера, резко возрастало количество активных соединений и сервер начинал отрубать входящие. Пока решили установкой твёрдотельных дисков. Возможно придётся кластер организовывать. При том что и процессор и память не кончились. Производительность упёрлась в дисковую подсистему. Ваш подход на нашем сервере, только усугубил бы ситуацию при неблагоприятных обстоятельствах, либо не улучшил бы.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  Поверонов ( Слушатель )
17 ноя 2010 01:51:32

Давайте рассмотрим Вашу ситуацию. Не совсем правда понятно, что здесь можно считать сервисом. Давайте условно считать сервисом каждый процесс, обращающийся к отдельному файлу. Вообще-то Вы описали именно тот случай, который и хочется избежать, когда все сервисы борются друг с другом за общий ресурс, в данном случае - файловую систему.
В обсуждаемом варианте новой ОС каждый сервис имел бы собственный ресурс - отдельную файловую систему- пусть хоть и с одним файлом, и конкуренция на уровне индексов файловой системы была бы развязана. Конечно останется конкуренция на уровне канала ввода-вывода, но она разрешима по круговой очередности: обратился к каналу - получил наименьший приоритет и жди пока он подрастет, чтобы снова схватить канал.
Но организация очередей не может полностью компенсировать недостаточность ресурса - в вашем случае, видимо, слабость дисковой подсистемы. Если у Ваших процессов велика доля операций чтения, то может помочь дополнение оперативной памяти для увеличения буферного пула.  Для этого правда нужно иметь 64-битную ОС. На 32-битной 4G - физический предел. Но если все процессы - пишущие, увеличение буферного пула бесполезно.
Если на сервере есть RAID контроллер, рассмотрите возможность подключения внешнего дискового поля типа IBM EXP3000 с большим числом неёмких дисков. RAID-0 ( striping ) практически увеличивает производительность дисковой системы кратно числу дисков под RAID-0. Если денег хватит, еще лучше ставить RAID-10 ( mirror+striping), тогда и диски легко менять.
Что касается SSD, то производительность MLC сравнима с 15k дисками, но имеет ограничение числа операций записи. При высокой "изменчивости" Ваших файлов SSD MLC могут требовать частой замены.
В этом отношении SSD SLC намного более устойчивы, но жутко дороги пока. Но богатым красиво жить не запретишьУлыбающийся
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
  bjaka_max ( Слушатель )
17 ноя 2010 09:07:39

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

Проблему решило маленькое время доступа твердотельников. Обычные диски кстати сыпались тоже, только держись.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  Поверонов ( Слушатель )
19 ноя 2010 00:31:54

Хочу напомнить, что файловые системы создаются не на дисках, а на разделах дисков ( partitions ), а этих разделов Вы может нарезать сколько понадобится. Для гибкости нарезки можете использовать lvm.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
  bjaka_max ( Слушатель )
19 ноя 2010 06:50:42

ну при чём тут это... я ж вам говорю, система уткнулась во время позиционирования головок диска, разделы то как тут помогут?
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
  cyberone ( Слушатель )
19 ноя 2010 09:59:38

Увеличьте кэш  8)
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  ata ( Слушатель )
19 ноя 2010 13:29:07

Проблема ограничений на iops дисковой подсистемы легко решается созданием кэш-буфера в размер дисковой подсистемыВеселый
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  openal ( Слушатель )
20 ноя 2010 20:10:07

Ну размер, а следовательно и сумма определяется условиями задачи, если строим не супер-пуперкомпьютер.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  ata ( Слушатель )
20 ноя 2010 21:51:15

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

Любая задача имеет несколько вариантов решения. "Быстро, качественно, дешево - выберите любые два!" Например, для задачи "дисковая подсистема с туевой кучей (скажем, 10к) iops":

"Быстро и качественно": Промышленная СХД (HP EVA, Netapp FAS, EMC, Hitachi AMS и т.п.). Цены начинаются от 100 к (и, если честно, эта сумма - только на "попробовать", по большому счету). Нормальное решение - где-то плюс-минус мильончик уёв.

"Быстро и дешево": это кучка бытовых SSD. Никто не даст гарантии, что они не сдохнут пачкой в тот момент, пока перестраивается рейд-массив после падения первого из них.

"Качественно и (сравнительно) дешево": это городить огород с доп.контроллерами, внешними полками под диски, тщательной оптимизацией софта, необходим постоянный мониторинг и, в случае чего, срочная закупка дополнительного оборудования. В рамках линейки HP - что-то типа сервера с полкой MSA70 (которая до 70 дисков). Но интересно, какие слова будут говорить люди, когда выяснится, что производительность системы надо бы еще немного поднятьУлыбающийся

А теперь угадайте, на какой вариант обычно хватает выделенного бюджета?Веселый

ps. А про "кеш в размер дисковой подсистемы"... Я сейчас отдаю серверам 3.6 ТБ usable space. Сколько будет стоить BBWC такого объема - предлагаю догадаться самостоятельноУлыбающийся
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  basilevs ( Слушатель )
17 ноя 2010 15:05:27


Ну да. В такой ситуации - или сразу переход к твердотельникам, с их нулевым временем доступа, или городить хитрый огород из маппинга каталогов общего дерева на отдельные физические RAIDы. Чтобы развести обращения к этим маленьким файлам на разные физические диски. В случае борьбы за быстродействие базы данных мы разводили группы таблиц/индексов на отдельные физические диски (использовалось обычное "зеркалирование", а не RAID5, ибо так было эффективнее).
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  ata ( Слушатель )
17 ноя 2010 16:31:21

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

Во вторых, если есть бюджет, то рассмотрите вопрос о приобретении внешней полки или дискового массива. Я, за бедностью, поставил HP MSA, у Netapp есть неплохие машинки 2040, выше - уже 3000, они уже хорошо стоят. Но надо знать потребные иопсы.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
  ata ( Слушатель )
17 ноя 2010 08:41:13

Ну в VMware примерно так и есть: на каждую ВМ выделяется отдельный своп файл. Правда, в настоящий момент цена даже серверной оперативки позволяет поставить ее достаточное количество, так, что узким местом будет процессор или ОИ (см. ниже).
Цитата
Насчет доступа не думаю, что возможно забить очередь io-операций так,что в нее больше никому не протиснуться. Всё-таки все современные серверы должны иметь внутренний или внешний аппаратный RAID контроллер, который сам организует и кэш блоков обмена и очередь операций.
И вообще трудно представить, как можно перехватить канал доступа, так что в него никто больше не втиснется, всё таки io имеют самые большие таймауты, разве что задать цикл асинхронных io-операций.
Это наверное можно предупредить на уровне ОС, поддерживая круговую дисциплину обращения процессов к каналам io.


Ндаа...

Докладываю: в настоящий момент существует фундаментальная проблема ограничения количества iops на жестких дисках. Самые быстрые 15к дают около 200 iops, 10к - около 150. И если в DL360 я могу спокойно набить 24 гига оперативы (а можно и больше, смысла нет), то поставить больше 8 дисков - не могу. А это - примерно 1500 iops, причем - в теоретическом максимуме, на практике - меньше.

Твердотельные диски, не имеющие таких ограничений, имеют либо космическую цену при мизерных объемах (60-гиговый HP стоит порядка 1200 баксов в онлайн-конфигураторе, ЕМНИП), либо ограниченное число перезаписей у MLC - примерно 3-5 тыс. на ячейку.

В сухом остатке имеем: своппинг и пейджинг давно перестали быть жизненно важной технологией, это - просто гарантия от внезапного исчерпания памяти. Если система свопится в моменты нагрузок - пора в магазин.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  Поверонов ( Слушатель )
19 ноя 2010 00:22:55

Вы кажется пытаетесь представить ограничения Вашего конкретного контроллера Smart Array P410i для HP - ProLiant DL360 как "фундаментальную проблему ограничения количества iops на жестких дисках". Если Ваш контроллер не способен контролировать более 8 дисков, это еще не фундаментальная проблема. По Вашему же совету зайдите в магазин:
http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/index.html
и Вы сможете выбрать себе контроллер до 108 дисков.
Но вообще-то мы обсуждали не наличие общего ограничения на производительность io, которое в любой системе всегда известно, а вопрос надо ли ограничивать доступ процессов к каналу io, чтобы предупредить захват канала одним из процессов в ущерб другим.На мой взгляд это может регулироваться очередностью доступа процессов к каналу без каких-либо явных ограничений.
Нельзя не согласиться с Вами, что своппинг и пейджинг "просто гарантия от внезапного исчерпания памяти". Это конечно не значит, что о них пора забыть навсегда. Пики случаются, и иметь буфер на такой случай не помешает, хотя бы потому что можно не успеть сбегать в магазинУлыбающийся.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
  ata ( Слушатель )
19 ноя 2010 11:58:00

8 дисков - это ограничения конструктива DL360, а не контроллера. Я это писал к тому, что в моей практике ограничения на объем оперативной памяти значительно слабее, чем на количество шпинделей - сравните процесс добавления нескольких планок памяти и установки и настройки контроллера, доп.полки (полок), а также цену железок.

Слова "фундаментальное ограничение" относилась к иопсам в рамках конкретной системы. Если человеку нужно 100к иопсов, то и "контроллер на 108 дисков" слабо поможет. И не забываем, что если задача потребляет такое io, то там есть и другие требования - типа доступности, надежности, и т.п. И все это подитоживает строчка под названием "бюджет".

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


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

У Бяки_Макса возникла типичная проблема: "зависание" системы из-за несоответствия требований задачи к io и возможностей железа. Обойти такое несоответствие в софте невозможно, о чем я и пытался донести мысль.
Цитата
Нельзя не согласиться с Вами, что своппинг и пейджинг "просто гарантия от внезапного исчерпания памяти". Это конечно не значит, что о них пора забыть навсегда. Пики случаются, и иметь буфер на такой случай не помешает, хотя бы потому что можно не успеть сбегать в магазинУлыбающийся.



Конценсцус.Улыбающийся
  • +0.00 / 0
  • АУ
 
 
 
  Поверонов ( Слушатель )
14 ноя 2010 01:57:02

Что Вы конкретно имеете в виду, что виртуализация аппаратная. Кто-то уже загнал гостевую ось в какое-нибудь надцатое ядро ? Или всё-таки гостевые ос по прежнему остаются процессами софтовой виртуальной машины.
  • +0.00 / 0
  • АУ
 
 
 
 
  bjaka_max ( Слушатель )
14 ноя 2010 09:37:43

Я имею в виду обычный intel vt например. "гостевые" ос управляются гипервизором работающим в root operation режиме. А гипервизор (это вообще не ос в традиционном смысле) только распределяет между ними ресурсы.
  • +0.00 / 0
  • АУ
 
 
 
 
  ata ( Слушатель )
14 ноя 2010 11:10:56

VMWare.
http://www.vcritical…ze-itself/
  • +0.00 / 0
  • АУ
 
 
  mrt789 ( Слушатель )
13 ноя 2010 20:39:12


"Все уже украдено до нас!" (c)

http://ru.wikipedia.org/wiki/Xen
http://ru.wikipedia.…ingularity
http://ru.wikipedia.org/wiki/Erlang

>Отличительной особенностью данной ОС является использование идеологии программно-изолированных процессов (Software Isolated Processes, SIP), похожих на легкие процессы языка Erlang, общение между которыми происходит исключительно посредством сообщений. В отличие от традиционных ОС, защита таких процессов в Singularity производится не путем организации аппаратно-защищенных адресных пространств, а путем использования типобезопасного подмножества промежуточного языка (MSIL) и его верификации перед компиляцией в родной код процессора. Каждый SIP обладает своим объектным пространством, «сборщиком мусора» и средой периода исполнения. Для таких процессов не допускается совместное использование памяти, и они не имеют возможность модифицировать свой код, что усиливает гарантии надежности работы программы в SIP.

В итоге связка вида: железо <-> [ ВМ1 <-> ОС нового поколения (по сути тоже ВМ) ] <-> серверная часть прикладного ПО <- некий протокол -> клиентская часть прикладного ПО на иФоне (или другом потребительском девайсе). Вся серверная часть хостится на облаке, эффективно распараллеливаясь, а клиенту продается подписка. В качестве механизма связи - LTE и др.
Плюс еще важно проработать механизм взаимодействия между таким сервисами(например, чтобы воспользоваться услугами другого сервиса как надежной (No)SQL БД, автоматически разделяя с ним доход от подписки). При наличии развитого рынка системных сервисов и доступных сердств разработки создание сервисов высшего порядка с произвольной масштабируемостью станет вполне посильным делом (фейсбук за два дня: бразуер клиента <-> веб приложение в облаке <-> подписка на БД там же - все за 50 баксов в месяц для начала, а уже если оно выстрелит....). Наиболее перспективные направления: виртуализация (3-4 глобальных игрока), перспективные ОС/рантаймы (1-2 игрока), хозяева облаков (10-15 игроков, с явным отрывом 2-3, которые вряд ли будут делиться своими технологиями) + они же будут поставщиками системных сервисов, разработчики железа (5-6, в 2-3 регионах), разработка инструментария для создания сервисов (по числу ОС + 2-3), глобальные платежные системы (2-4), разработка сервисов и клиентских интерфейсов к ним (много, но за счет глобальности придется жестко конкурировать). Ну и попытки создать себе монополию будут, куда уж без этого.

Добавлю только, что облака скорее всего еще больше повысят степень глобализации и затруднят конкуренцию с лидерами (второй MS не нужен, и второй Google, как это ни странно, тоже, да и ЯблоМагаз №2 вряд ли будет популярен). А один единственный удачный сервис доступен всему миру. Ну и плюс к этому - это уже не вполне будушее... ЯблоМагаз (Андроид Маркет), ГуглДокс(Мап, Мейл, Гаджет, опередивший свое время Вейв), Амазон и пр. пусть пока и на "старых" технологиях (тут вообще революции может и не произойти).

Google Maps практически идеальный пример, учитывая сколько сервисов и ПО на нем основано.
  • +0.00 / 0
  • АУ
 
 
 
  Поверонов ( Слушатель )
14 ноя 2010 01:26:56

Но почему-то MS остановило работу над Singularity.
Цитата
Singularity 1.0 была завершена в 2007 году. Исследовательский пакет Singularity 1.1 Research Development Kit (RDK) был выпущен под лицензией Shared Source и допускает академическое некоммерческое использование; пакет доступен на CodePlex. 14 ноября 2008 г. был выпущен Singularity RDK 2.0. Дальнейшая разработка сосредоточена на инкрементальных релизах.


Может вояки увели разработчиков ?
  • +0.00 / 0
  • АУ
 
<< Тред №273609
Тред №273611 >>