Приглашаем на встречу Windows Azure Group – на встрече можно будет пообщаться с пользователями наших сервисов, узнать о новых возможностях Windows Azure и послушать интересные доклады о проектах использующих технологии WindowsAzure :

Регистрация бесплатная, зарегистрироваться для участия вы можете через МойКруг, linkedin : Windows Azure Russia – user group.

В ближайший вторник 13 декабря Microsoft проводит сессию тренингов Learning Windows Azure – тренинги проводятся гуру облачных вычислений из Microsoft – для тех кому повезло оказаться в Редмонде доступен офф-лайн вариант в кампусе Майкрософта, для остальных есть веб-трансляция Learning Windows Azure на Channel9 и хештег #WindowsAzure с помощью которого можно задавать вопросы ведущим. Расписание тренингов отлично подходит под западное побережье США, в евройпейской части России все это в онлайне будет глубокой ночью. Регистрация на участие в тренинге ( для тех кто в Редмонде :-) ) доступна на Learning Windows Azure Event, Scott Guthrie обещает освещать всё происходящее в своем твиттере и блоге.

Расписание сессий по московскому времени :

  • 21-00 – 22:30 : Начало работы с Windows Azure SDK – Microsoft VP Scott Guthrie )
  • 22:45 – 24-00 : Данные в облаках и облачное хранилище ( SQL Azure и файловые хранилища ) – Microsoft Technical Fellow Dave Campbell
  • 00:15 – 1:15 : Channel9 Cloud Cover Show – веб-кастов Channel9 Cloud Cover Show вживую с Steve Marx и Wade Wegner.
  • 01:30 – 2:30 : Полный цикл разработки для Windows Azure в Visual Studio – разработка, отладка, деплоймент с Jay Schmelzer
  • 2:45 – 3:45 : Лучшие паттерны проектирования масштабируемых облачных приложений с David Aiken
  • 4:00 – 5:00 : Ответы на вопросы ( не забываем про #WindowsAzure ) с Scott Guthrie, Dave Campbell и Mark Russinovich ( тот самый из systeminternal.com ) !

Также на этой неделе будет еще одно похожее мероприятие организованное канадскими клаудными экспертами – A Whole Week of Windows Azure Training Opportunities – это целая серия онлайн трансляций посвященных технологиям Windows Azure, эту серию трансляций будет проводить Jonathan Rozenblit. Ко всем трансляциям будет доступен live-chat, после завершения трансляции записи будут доступны на Channel9.

Stay tuned!

8 декабря 2011 CloudGroup проводит очередной круглый стол – на этот раз будет целых 2 темы – первая посвящена публичным клауд провайдерам ( Боков Алексей ), второй доклад посвящен научным клаудам и использовании облачных вычислений в научных приложениях ( Шилеев Кирилл ) – презентации и ответы на вопросы см.ниже.
Тема 1 : Лидеры рынка публичных облаков – сравнительный анализ

  • Вычислительные ресурсы
  • Хранилища данных
  • Базы данных
  • Дополнительные сервисы

Тема 2 : Научные облака

  • Особенности требований к научному ПО
  • Гриды vs Клауды
  • Что в будущем : гибридные облака

Зарегистрироваться для участия в круглом столе можно здесь.

Подробнее о прошедших и будущих событиях можно узнать в профиле CloudGroup

upd
Презентация Кирилла Шилеева – Научные облака – прошлое, будущее, настоящее
По многочисленным просьбам отдельно публикую ссылку из последнего слайда : Can Clouds Replace Grids? A Real-Life Exabyte-Scale Test-Case by J.D. Shiers, CERN, Geneva, Switzerland

Моя презентация – Публичные клауд провайдеры – сравнение

20 октября 2011 CloudGroup проводит очередной круглый стол – на этот раз мероприятие будет посвящено приватным облакам.
Краткие тезисы доклада и дискусии :

  • Что такое приватное облако и зачем оно нужно
  • Обзор решений в области приватных облаков
  • Проект OpenStack – open source решение для построения приватных облаков
  • От публичного облака к приватному
  • Взгляд на облачную парадигму завтрашнего дня

Рассказывать про OpenStack будут разработчики проекта OpenStack в России – Илья Алексеев и Эльдар Нугаев. Зарегистрироваться для участия в круглом столе можно здесь.

Подробнее о прошедших и будущих событиях можно узнать в профиле CloudGroup

update Выкладываю саму презентацию : Приватный клауд на базе OpenStack

Алексей Рагозин будет рассказывать про Сборка мусора в #Java и борьба со stop-the-world паузам . Все желающие – welcome : 13 октября 2011, 19-00, м.Маяковская ).

6 октября мы (CloudGroup) будем проводить открытый круглый стол посвященный облачным вычислениям – обсудить предлагается в первую очередь бизнес аспекты облачных вычислений. Формат – презентация с последующей дискуссией. Презентационная часть состоит из нескольких частей :

  • Сloud computing crash-course – IaaS, SaaS, PaaS с примерами.
  • Инфраструктура как сервис для стартапов и крупных компаний – общие черты и различия при использования облачных вычислений.
  •  Облачные приложений на базе IaaS – примеры успешных внедрений

Начало в 19-00, географически мероприятие будет проводиться в Москве, недалеко от м.Белорусская, участие бесплатное, за приглашениями обращаться ко мне на почту bokov-aleksej’собака’yandex.ru
или через МойКруг. Подобрнее о прошедших и будущих событиях можно узнать в профиле CloudGroup

По итогам: cама презентация доступна здесь :  Бизнес аспекты облачных вычислений

Ответы на некоторые вопросы которые я вчера не смог полностью осветить:

  1.  Локальные российские SaaS сервисы : я бы отметил Электронный бухгалтер Эльба, Мегаплан (CRM) ,1С Битрикс как SaaS услуга, МойСклад.
  2.  Рост рынк облачных услуг до 500 млн$ в 2015 году :  рост рынка будет за счет увеличения доли облачных услуг в ИТ – “В 2015 г. седьмая часть затрат на коммерческое ПО, серверы и системы хранения будет приходиться на облачную инфраструктуру. По прогнозу IDC, в 2015 г. на долю публичных облачных сервисов будет приходиться 46% роста общих расходов на основные категории ИТ — приложения, разработка и развертывание приложений, инфраструктурное ПО, системы хранения и серверы.Три четверти расходов на публичные облачные услуги будут направлены на оплату «ПО как услуга» (SaaS). Основными покупателями серверов и систем хранения станут провайдеры SaaS-услуг, которые займутся построением своей инфраструктуры.” – см.IDC: Облачные услуги будут стимулировать рост рынка ИТ в ближайшие 25 лет

 

smartphone market share android iphone blackberry

То что андроид будет доминировать (70-80% рынка для смартфонов и больше половины для tablet PC ) это вполне очевидно, любопытно было бы видеть распределение внутри андроида по производителям устройств ( и версиям ОС ) и андроидным маркетам ( т.к. у многих производителей есть свои маркеты для приложений ).

Hello world c++

email versus wiki
Комментарии как говориться излишни.
via Email vs Wiki


“I have to say, I’m not a big fan of cloud computing” by Drew Dernavich/ The New Yorker 2.07.2011/

Amazon анонсировал собственный портал для Android приложений :

Google представил Android 3.0 ( Honeycomb ) на базе устройства LG /G-Slate :

Amazon анонсировал микро инстансы в EC2 – теперь самый дешевый instance в линейке EC2 стоит 2 (два) цента в час и похоже что хостинг на EC2 становится дешевле чем low-cost dedicated – за 2 цента в час ( 15 долларов в месяц ) получаем linux с root/ssh и всеми соответствующими пирогами. Есть конечно и подводные камни – во первых производительность таких micro instance будет явно очень небольшой ( см – Amazon EC2 Micro instance, how fast is it? ), во вторых собственно дискового пространства на таком micro instance нет и для хранения данных в файловой системе надо использовать EBS, что стоит некоторых небольших денег – 10 центов в месяц за каждый Гб хранимых данных плюс 10 центов за каждый миллион операций ввода-вывода.

AWS как хранилище данных

По состоянию на март 2010 года в Amazon S3 хранится 102 миллиарда объектов, если принять за основу расчеты Is number of objects true indicator of Amazon S3 growth? – 18 миллиардов объектов соответствуют 10 Пт данных, то получаем что сейчас в S3 хранится около 50 Пт данных ( на март 2010 ). Почти наверняка это заниженная оценка, поскольку для хранения петабайт данных Amazon S3 предоставляются специальные условия – видимо есть спрос на хранение таких объемов данных в S3. Если же брать EC2, то только предоставление дискового пространства для запущенных instances требует как минимум 8 Пт ежедневно – см Amazon provisioning 7 petabytes of storage per day.

AWS как вычислительный ресурс

Согласно Amazon’s EC2 Generating 220M+ Annually ( данные на октябрь 2009 ) – 80 процентов серверов приходится на зоны US, в сумме около 40 000 физических серверов, примерно одна пятая инфраструктурных мощностей EC2 используются для нужд сервисов обслуживающих amazon.com. Распределение по типам инстансов :
amazon ec2 usage rates

Amazon Web Services по прежнему лидер рынка – см State of the cloud – 2010 August

AWS как хостинг

EC2 может быть дешевле обычного dedicated хостинга ( имеется в виду с root ssh доступом ) – самые дешевые instance Amazon – micro instances  стоят 2 цента в час, что дает 15 долларов в месяц. В среднем ( имхо ) бюджетные предложения хостинга linux ( root ssh ) стоят в районе 20-30 USD в месяц. Производительность micro instance очевидно будет ниже чем m1.small – см Amazon EC2 Micro instance, how fast is it?, второй, более существенный, минус – дисковое пространство на таких instance отсутствует и в качестве хранилища данных ( подмонтированной файловой системы ) можно использовать только EBS, а EBS стоит некоторых денег – 10 центов в месяц за 1 Гб данных плюс 10 центов за каждый миллион операции ввода-вывода. Тем не менее возможность получить кластер из 200 серверов всего за 4 USD в час очень привлекательная и наилучшим юзекейсом для micro instances имхо будет высокораспределенный вычислительный грид, что впрочем не уменьшает привлектельности использования EC2 как дешевого хостинга с root доступом.

 

На “сладкое” – анатомия instance id и расчет количества ежедневно запущенных instance – Amazon EC2 usage estimates – около 50 тысяч инстансов в пределах одной геозоны в сутки ( данные на Oct, 2009 ) :
amazon zone eu-west-1.

По горячим следам презентации в мейл.ру хочется немного дополнить мои ответы на вопросы из зала :
Q : Какова производительность EC2 instance ( по сравнению с реальным железом )?

A: Картинка ниже должна ответить на данный вопрос ( не забываем что в линейке EC2 есть и гораздо более производиельные instance чем m1.medium ),  по теме произвоительности EC2 ( и других клауд провайдеров )  можно посмотреть эту небольшую подборку ссылок – Cloud providers perfomance tests and monitoring.

Q: Трафик с EC2 – сколько стоит входящий трафик и сколько исходящий? Насколько оправдано например будет вынести краулинг веба в EC2 ?
A: Как я и сказал – внешний входящий трафик бесплатный, исходящий наружу стоит некоторых денег – см EC2 pricing. Трафик внутри сети ( в пределах региона ) – бесплатный. Теперь о деталях – исходящий трафик бесплатный до 1 ноября 2010, после будет тарифицироваться по 10 центов за Гб – так что времени бесплатно скачать весь интернет осталось не так много :-) При цене в 10 центов за Гб скачать весь рунет ( по данным яндекса 140 тысяч Гб только текста ) будет стоит 14 000 USD, а если говорить о инкрементальном апдейте в 2 Тб ( что вполне близко к реальности ), то один стоимость трафика достаточно невысока – всего 200 USD. Внешний трафик ( наружу ) – один Гб в месяц – бесплатно, далее в зависимости от объёма цена колеблется от 8 до 15 центов за Гб. Другая приятная для анонимного краулинга особенность EC2 – действительно большой выбор ip адресов – имеется возможность размещения instance в достаточно широком диапазоне подсетей и более того в разных географических регионах.

Q : Как ведут себя instance EC2 в некоторых нештатных ситуациях ( например когда кончаются сокеты или память ), какие там установлены лимиты?
A: Для меня неясно насколько поведение ОС под Xen отличается от ее поведения на настоящем железе, особенно в крайних ситуациях. Очевидно что все настройки лимитов на guest-OS доступны для редактирования, но также очевидно что всё это никак не влияет на настройки host-OS. Официальная точка зрения инженеров Amazon состоит в том, что то все лимиты устанавливаются также как и под реальным железом ( root + ulimit ) и запуск OC под системой виртуализации не играет тут никакой роли. Из найденных пользователями фич можно посмотреть по этому поводу например Get around EC2 filesystem limits (sort of), а вообще подозреваю что поведение будет иметь фичи не столько связанные с тем что мы запускаем сервер под EC2/Xen, сколько зависеть от образа который мы запускаем.

Q: Поддерживается ли hibernate в EC2 ? ( можно ли поднять приложение, “прогреть” кэш и сохранить это состояние, а потом когда нужно быстро поднять сервер? )
A: Для начала каким образом можно было бы сделать Hibernate – для этого необходимо к instance примонтировать EBS устройство ( отформатировать его и тп ) и сделать туда hibernate выключив instance – shutdown в данном случае означает что мы потеряли данный instance навсегда, EBS хранилище при это естесственно остается существовать и его можно примонтировать к любому другому запущенному instance. Таким образом hibernate можно реализовать как например запуск нового instance такого же типа с автоматическим монтированием EBS с hibernate данными и восстановлением состояния системы из данных с этого EBS устройства. Насколько я могу судить эта фича достаточно востребована, но как я вижу, пока не реализована – см. EC2 Hibernate, Hibernating Ubuntu on EBS boot EC2 instances.

ps. Из остального – если хочется что-то cloud computing но на местной, российской площадке – посмотрите на Оверсан Скалакси.

На конференцию cloud-разработчиков и архитекторов CloudCamp приглашаются докладчики и спонсоры. CloudCamp – это сообщество клауд-энтузиастов-волонтеров которые организуют и проводят по всему миру технические конференции посвященные cloud computing и близким технологиям. Планируется проведение этого мероприятия и в Москве. Формат – выступления на клаудную и смешанную тематику, доклады участников и доклады спонсоров мероприятия. Так как докладчиков-не-спонсоров бывает намного больше чем отведенного времени, то список докладов выбирается путем голосования среди участников конференции, доклады спонсоров идут вне конкурса. Мероприятие является некоммерческим, спонсорское участвие требуется только на оплату авиабилетов и гостиницы для организатора со стороны cloudCamp ( Yosu Cadilla ) и помощи с помещением ( часто это проводится либо в конференц румах компаний спонсоров ), плюс кофе брейки и пицца для участников.

Со всеми вопросами можно обращаться ко мне ( bokov-aleksej dog yandex.ru , skype : alexey_bokov ) или в linkedin группу CloudCamp Russia Cloud Computing UN-conference.

То о чем так долго твердили большевики клауд евангелисты случилось – HPC на EC2 таки пришло ( см – New Amazon EC2 Instance Type – The Cluster Compute Instance ) в виде HVM виртуализации ( Xen/CentOS ) вместо паравиртуализации ( Xen/много_разных_ос ) используемой в EC2 сейчас. Ожидается что виртуалки запускаемые под HVM будут сильно быстрее, сеть обещают 10Гбит, что безусловно хорошо. Создавать HPC кластеры как обычно можно через API парой команд – создать имя кластера, и второй командой запихнуть в этот кластер столько то виртуалок :

$ ec2-create-placement-group bokov_super_cluster -s cluster
$ ec2-run-instances ami-2de43f55 --type cc1.4xlarge --placement-group bokov_super_cluster -n 8

ami-2de43f55 – это CentOS ( ничего другого пока нет – не поддерживают HVM ? ), 8 – сколько нодов в кластере,
cc1.4xlarge – тип ноды ( Quadruple Extra Large – 33.5 ECU (EC2 Compute Units), 23 GB of RAM, 1690 GB storage ).

HPC кластеры от EC2 базируются на самом мощном инстансе из линейки AWS который запускается под HVM, причем в случае с Cloud Compute cc1.4xlarge стоит дешевле ( 1.60 против 2.40 ) чем в случае простого, не HPC-кластерного, использования. Доступно все это пока только в одном регионе – us-east ( физический локайшн серверов, конечно же пользовать все это можно из любой точки мира ), постепенно думаю что расширят ее и на другие регионы. Как уже упоминалось из операционок доступна сейчас только CentOS, для других ОС Amazon предлагает делать образы самостоятельно, но имхо лучше подождать немного пока этого не сделают. И еще немного по поводу производительности -  как утверждается в New Amazon EC2 Instance Type – The Cluster Compute Instance народ из AWS сделал кластер из 880 HPC узлов с производительностью 41.82 MFlops (запускали High Performance Linpack запущенный на 880 инстансах Cluster Compute (7040 cores) – что пример равно 146 месту в top500 суперкомпьютеров.

Если совсем-совсем честно, то конечно же HVM это все равно Xen и всё равно виртуализация, что имеет свои явные плюсы в виде скорости _скалирования_ кластера, но и по сравнению с “просто железом” верхняя планка по производительности ( в пике? ) все равно будет ниже. Из HPC + cloud computing еще раз хочется отметить Penguin On Demand – это HPC кластеры on demand ( cloud computing!) из “настоящего” hardware, без виртуализации. Penguin-ы уповают на то что их cloud будет сильно быстрее в смысле общего времени выполнения задач. Подробно в POD я пока не копался – остаётся открытым вопрос про API ( свое ПО для управление кластерами Penguin-ов – SkyId ClusterWare + TaskMaster Suite + Integrated Managed Framework, API явно есть, не понятно как из своих приложений управлять кластером ) и про то насколько быстро кластер будет скалироваться – с одной стороны конечно Pay-As-You-Go, но тем не менее SLA не гарантируют и про динамическое изменение размеров кластера сказано что “can be rapidly scaled by Penguin so POD can grow its capacity as needed” ( POD = Penguin On Demand, по умолчанию в нем доступно 1280 ядер, видимо платить надо за все сразу? ), интересно а если надо уменьшить размер кластера ? Еще небольшое замечание – Penguin-On-Demand на сегодня также как и Amazon HPC работает с CentOS.

И немного о сравнении производиельность SVN с GIT ( да я знаю – ‘чертовы гики, пректите мигрировать с svn на git и обратно – пишите код и не занимайтесь ерундой!‘ (c) Никита Филиппов ). Даже скорее о сравнении производительности svn и git в случае если пользоваться git-ом точно так же как svn – это гораздо лучше отражает use-case миграции с одной системы контроля версий на другую, потому что большинство людей после миграции будет пользоваться git-ом в режиме максимальной совместимости с svn, хотя бы просто потому что за много лет они уже привыкли к svn-парадигме работы с репозиторием.

Итак что мы имеем – svn и git проинсталлированные на одном и том же сервере, изначально оба репозитория пустые. Я применил одну и ту же последовательность действий с одними и теми же данными и замерил время выполнения этих операций – мои тесты в основном касались ряда типичных операции с системами контроля версий – добавить данные, сделать checkout, поменять данные, обновиться из репозитория и тп. Соответственно, я замерял время требуемое как для комитов изменений, так и для получения обновления от этих изменений. Конфигурации svn и git использовались стандартные, я ничего не правил в конфигах – все настройки должны быть используемыми по умолчанию. Всеобъемлющего теста конечно у меня не получилось – я не проверял удаление, создание бранчей, merge и многие другие вещи – потом будет чем дополнить этот тест.
Сразу оглашу результаты теста – git быстрее чем svn примерно в 2-3 раза, единственная проблема которая может возникнуть с git – это работа с большими ( > 300 мб ) файлами, при этом возможна даже ситуация когда git завершится с ошибкой при попытке закомитить файл большого объема ( в моем случае падение производительности началось от 100 мб и окончательно git свалился с ошибкой на комите файла 1200 мб ). Эта довольно неприятная ( хотя если честно очень мало кому приходится комитить файлы размером больше 300 мб ) особенность git-а вроде как исправлена в проекте git-bigfiles, но я подробно его еще не смотрел.

svn git svn/git
Test 1 : adding boost 1_43 add ( 1 sec )+ commit ( 600 sec ) = 601 sec add ( 3 sec ) + commit ( 86 sec ) + push ( 612 sec ) = 701 sec 0.85
Test 2: checkout repository after Test 1 svn co = 109 sec clone = 18 sec 6.05
Test 3 : поменял 346 файлов – добавил в начало одну строку(комментарий) svn commit = 5 sec commit(2 sec ) + push ( 2 sec ) =4 sec ~1
Test 4: update after this Test 3 svn update = 15 sec git pull ( 7 sec) ~2
Test 5: поменял аналогичным образом ( добавил первую строку ) в 5363 файлов svn commit = 103 sec commit ( 6 sec ) + push ( 18 sec ) = 24 sec 4.29
Test 6: update after Test 5 svn update = 28 sec git pull = 12 sec 2.3
Test 7: добавил репозиторий из “реальной жизни” ( 2.6 гб разносортных данных, большей частью с++ код ) svn add(21) + svn commit(1h 2m 25s) = 3 766 sec add (38 ) + commit ( 1m23 ) + push ( 18m28 ) = 1 m 51 + 18m 28sec= 20 m 19 sec = 20 m 19 sec = 1 219 sec 3.1
Test 8: update after Test 7 svn update ( 11m 58 sec ) = 718 sec git pill = 5m 27 sec = 327 sec ~2.2
Test 9: имитация рефакторинга – добавил принудительное использование namespace ( std:: ) svn commit ( 1m 28 sec ) = 98 sec commit (5 sec ) + push ( 3 sec) = 8 sec 12.25
Test 10 : update after Test 9 svn up = 22 sec pull ( 9sec) 2.4
Test 11: full checkout project svn co 12m 45sec = 765 sec pull ( 4 min 3 sec ) = 243 sec 3.14
Test 12: тест на файлы большого размера – лог apache ( 50 mb ) svn add(3) + commit (1m 27s ) = 1m 30 sec = 90 sec add (3) + commit(6) + push (1m 18 sec) = 1m 17 sec = 77 sec 1.16
Test 13 update after test 12 up = 26 sec pull = 17 sec 1.52
Test 14 : тест на большие файлы : все c++ исходники одного проекта одним файлом ( 70 mb ) add(3) + commit(1m 15 sec) = 1m 18 sec = 78 sec add (2) + commit (2) + push ( 56 sec ) = 1 m = 60 sec 1.3
Test 15 : update after Test 14 up = 28 sec pull = 14 sec ~2
Test 16: тест больших файлов – 100 МБ xml add(3) + commit (8m 37 sec)= 8m 40 sec = 520 sec add (9 sec) + commit (1) + push ( 24m 34 sec) = 24 m 44 sec = 1484 0.35
Test 17 : update after Test 16 up = 52 sec pull = 47 sec 1.10
Test 18 : тест больших файлов – 300 MB xml add ( 1 ) + commit( 9 m 26 sec )= 9m 27 sec = 567 sec add (3) + commit(8) +push (17m 12 sec) = 17 m 33 sec = 1053 sec 0.53
Test 19: update after test 18 1m 39 sec pull= 1m 29 sec 1.1
Test 20 тест больших файлов : 1200 MB xml 1h 24m 34s failed ?
Test 21 : update after Test 20 5m 47 sec failed ?
~2.6

Итак – мы видим что в среднем git в 2.6 раза быстрее чем svn. Мои тесты не прендуют на точность и, как я уже заметил, далеко не все use-case были проверены, но тем не менее определённые выводы сделать можно. Мы видим что git быстрее больше чем в раза почти всегда, не совсем всегда – это работа с большими файлами – там скорость работы git уже равна либо даже сильно хуже чем у svn, и более того в моем случае git push после добавления большого ( 1200 Мб ) файла даже завершился с ошибкой – ‘fatal: Out of memory, malloc failed


Test1
boost 1_43 C++ library : 29135 файлов ( всего 31609 объектов включая папки ), общий размер – 286 Mб

Test 3
Добавил первую строку-комментарий к файлам отобранным по маске:

find ./ -name "*a???.cpp" -exec sed -i 1i"//test comment `date` : {}" {} \;

Test 5
Добавил первую строку-комментарий к файлам отобранным по маске “*.cpp”

find ./ -name "*.cpp" -exec sed -i 1i"//big test comment2 `date` : {}" {} \;

Test 7:
Добавил реальный проект из реальной жизни : огромное количество исходников ( cpp, perl, erlang, makefiles, bash ), документация в MS word формате, картинки, pdf’s, собранные бинарники ( моветон, но таков реальный проект ), файлы ресурсов и тп, суммарно – 4605 files, общий размер около 2.6Гб

Test 9:
Небольшая имитация рефакторинга – добавил использование указания namespace std:: для все cout и cerr. Кстати не уверен что это реально безобидное изменение :-)

find ./ -name "*.h" -exec sed -i "s/ cerr/std::cerr/g" {} \;
find ./ -name "*.cpp" -exec sed -i "s/ cerr/std::cerr/g" {} \;
find ./ -name "*.cpp" -exec sed -i "s/ cout/std::coutr/g" {} \;

Test 11: checkout всего репозитория целиком

Test 12: тест больших файлов : добавил в репозиторий текстовый файл размером 50 Мб ( лог apache ).

Test 14: тест больших файлов : добавил в репозиторий текстовый файл размером 72 Мб ( сконкантерировал все с++ исходники одного подпроекта в один файл ).

Test 16: тест больших файлов : добавил в репозиторий текстовый файл ( xml ) размером 100 Мб

Test 18: тест больших файлов : добавил в репозиторий текстовый файл ( xml ) размером 300 Мб

Test 20: тест больших файлов : добавил в репозиторий текстовый файл ( xml ) размером 1200 Мб

git push failed с сообщением о memory leak : “fatal: Out of memory, malloc failed”

См также Version control systems : git, svn, cvs, mercury links

Термин клауд комьютинг ( облачные вычисления ) изначально обозначавший гибкое распределение ресурсов “по требованию” стараниями маркетологов стал синонимом виртуализации во всех ее проявлениях. Это соответствует общему тренду хайтек-маркетинга – от концепций в духе vBullshit в сторону парадигмы Bullshit-as-a-Service ( BaaS ).
SaaS bullshit PaaS bullshit bingo

Интервью Андрея Колесникова на ЭхоМосквы в программе Точка Плющева

via plushev
upd Еще одно интервью – .РФ без мата – поскольку russia.ru то в общем то ни о чём.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes