по крайней мере исходя из перечисленных тем обоих модулей я что-то не вижу чего-то эксклюзивного, за что можно заплатить 180к
конечно если компания готова заплатить, то слушателю как-то без разницы, даже 2млн не много, тут подходят пословицы «не свои, не жалко» и «нахаляву и уксус сладкий»
обычный минимальный набор базовых знаний, ключевое слово БАЗОВЫХ, по которым курсов и статей написано не просто много, а море, так как BigData & ML сейчас в тренде
если же ключевым является именно «курсов других крупных игроков рунета», то хочу вас расстроить, на этих курсах образование и закончится, так как все ключевые вещи идут на английском, а если знаешь english, то к чему отсылка на русских игроков?
p.s. Есть ли тут хоть кто либо, кто САМ платил, а не прошел по «бесплатной квоте» или за кого заплатили текущие работодатели?
Голый Hadoop в виде MapReduce со стримингом (который никогда не был действительно хорош) в Python???
Вы действительно не шутите когда в 2015 году предлагаете ручками писать map/reduce?
Первая часть по инструментарию легко и непринужденно решается hive/impala и обычным sql. К моменту когда первые ученики еще только будут заканчивать читать описание api, в вилабаджио будут праздновать вторая группа уже будет рисовать таблички и графики
По машинному обучению уж насколько я недолюбливаю spark за их маркетинг, но конкретно в данном случае он может справиться и с первым заданием и со вторым в разы быстрее.
Так как ваши пункты по чистке нормально укладываются в pipeline и каждый из них будет отдельный map без смешивания логики, то спарк их прогонит за один проход. В хадупе или все в один map или пачку раз перезапускаем разные скрипты с сохранением промежуточных результатов, в любом случае не очень красиво.
Как результат у вас или datascienist закопается в инженерных нюансах как делать map/reduce, или если рассчитано на инженеров, то они в математики потом увязнут. Так на кого курс рассчитан?
1) github.com/golang/go/issues/11485
On multi-gigabyte heaps, about half of our mark termination time (~5ms of ~10ms at 4GB) is spent in the loop over all spans in the _RootSpans case of markroot. We should fix this for 1.6.
то есть только финализаторы на 4GB не считая всего остального уже могут вызвать больше 10ms в STW
2) отсутсвует возможность compaction, следовательно привет фрагментированная куча, а для long running приложений эта проблема существует
и еще несколько пунктов, но пока я не видел ни одного, которого уже не сделали в других VM, пилятся вещи обязательные для любого CMS который не хочет быть совсем уж тормозным, поэтому и хочется узнать великий секрет почему на хипе в 64GB у них не будет пауз больше 10ms
что значит «на время сборки», которая в некоторых приложениях может быть перманентной?
отлично, открываем слайд 15:
1) нарисовано, что stw у нас 1 и 3 ms и там все стоит
2) между этими моментами у нас 25% это GC, 20% приложение, остальное… 55% assist. WTF??? почему про это нигде не сказано? ведь обещали 25% gc и остальное приложению.
3) красиво нарисовано расстояние между сборками, там можно хоть один столбик оставить и сказать что мы не мусорим, но какое поведение будет если столбики эти будут идти один за одним, что легко случается при активном создании-удалении объектов? приложение получит 20% ресурсов???
я понимаю, что управлять приходиться самому, просто «размер в 2.2 от активного хипа» когда у тебя хип на 1-2GB это нормально, но когда у тебя он на 64GB и ты чтобы не просесть используешь только половину, то это немного странно (да это один из пунктов критиков azul jvm, он требует удвоенного хипа).
p.s. я внимательно читаю и слайды и отдельные доклады и по go и по другим языкам, так как хочется следить за направлением развитий gc особенно для больших хипов, но пока в go я вижу стандартные маркетинговые заявления не подкрепленные ничем (был один глобальный сборщик STW и перешли на CMS и сразу вброс про то что мы победили паузы, на практике лишь сделать очевидный для всех небольшой шажок в правильном направлении)
было бы желание, а 10ms для многих задач и в java достижимы, особенно если ставить условиями:
1) вы отдаете 25% ресурсных мощностей под gc
2) вы отдаете под gc удвоенный хип
The goal of the Go 1.5 (June 2015) Garbage Collector (GC) is to reduce GC latency, making Go acceptable for implementing a broad spectrum of systems requiring low response times. Quantitatively this means that for adequately provisioned machines limiting GC latency to less than 10 milliseconds (10ms), with mutator (Go application code) availability of more than 40 ms out of every 50 ms. Hardware provisioning should allow for in-memory heap sizes twice as large as reachable memory and 25% of CPU cycles, typically one out of 4 hardware threads, available for GC tasks. These goals align with a future with ever-increasing numbers of hardware threads and an ever-increasing amount of memory, all within an ever-decreasing power and expense budget.
Tactically, we will use a hybrid stop the world (STW) / concurrent garbage collector (CGC). The STW piece will limit the amount of time goroutines are stopped to less than 10 milliseconds out of every 50 milliseconds. If the GC completes a cycle in this time frame, great. If not, the GC will transition into a concurrent GC for the remainder of the 50 millisecond block. This process will repeat until the GC cycle completes. As a practical matter if one has a 50 millisecond response quality of service (QOS) requirement one should expect to have 40 milliseconds in which to do mutator tasks. These numbers assume hardware equivalent to a generic $1000 desktop box running Linux.
>> Java секунды в порядке вещей
все ведь зависит в первую очередь от дефолтного поведения и версии jdk, в 8ке с этим заметно получше ;) а дальше начинается большой простор для творчества и флагов
в общем виде никак, по крайней мере в oracle jdk
1) pauseless gc в azule, то habrahabr.ru/post/148322 пачка магии с защитой страниц памяти от чтения, исправление указателей во время выполнения и остальная магия
2) проект Shenandoah (который пилит RedHat, но в 9ку он точно не войдет), то там использовали Brooks forwarding pointer (JEP 189). в нете находится несколько докладов от разработчиков.
базовые вещи в виде CMS коллектора уже давно есть, в 8ке сделали параллельную initialmark, что значительно ускорило данную фазу.
также g1 имеется, но там тоже есть нюансы в виде stw на эвакуации и разрастания rememberset таблиц, но он уже дефолтом будет в jkd9.
>> В этом будущем нет места для пауз GC с «остановкой мира» (stop-the-world), которые были преградой для более широкого применения таких безопасных и надёжных языков, как Go.
кроме как с pauseless этого достичь нельзя =) ну или как выше было сказано один раз не пи... 10ms не STW.
>> но в 99.9% она будет ниже 10ms
а тут все зависит от приложения, чем больше потоков/горутин, тем больше у тебя точек root, тем по большему объему памяти это все размазано, то есть все больше random access в память нужно делать, который значительно медленней линейного сканирования.
>> Уверен, Хадсону об этом не нужно рассказывать.
Я же не говорю, что сомневаюсь в компетенции, но на данный момент нигде нету технических деталей почему это не скажется на производительности, а если вы ещё посмотрите на слайды 17 и 18, то там уже видно, что хоть 1.5 и обладает более предсказуемой производительностью для json, но на малых объемах хипа он сливает по скорости 1.4, а для splay на любых объемах немного медленней.
Именно потому что внимательно смотрел слайды и задал свой вопрос, так как бесплатный сыр бывает только в мышеловке.
конечно удачи в разработке, но и заявлять о великой победе супер gc тоже не стоит ;)
>> достиг цели уменьшить верхнюю планку пауз до 10мс
то есть 10мс это не STW, а просто постоим покурим?
наезды на java о том, что для работы с разными потоками ничего кроме локов не имеется тоже безосновательны, акка тут в помощь
>> Этот подход намеренно так сильно несоответствует большинству современных сборщиков мусора «энтерпрайз»-уровня
то есть CMS в jvm несуществует? там и STW на initialmark фазе и фаза remark которая проходит по вновь созданным объектам и тд
>> В трехцветном сборщике мусора, каждый объект может быть помечен, как белый, серый или чёрный, и мы рассматриваем кучу (heap) как граф связанных объектов. В начале каждого цикла GC все объекты белые. GC проходит всё корневые узлы (roots) графа, которые являются объектами, напрямую доступными программе — это глобальные переменные и переменные в стеке — и помечает их серыми. Затем GC выбирает серый объект, делает его чёрным, а затем сканирует его на наличие указателей и других объектов. Если скан обнаруживает указатель на белый объект, он делает его серым. Этот процесс повторяется, пока не останется серых объектов. В этот момент все белые объекты будут считаться недостижимыми и могут быть переиспользованы.
в большинстве случаев (допускаю, что у вас в команде это не так, но говорю про свой опыт) статический анализатор с максимумом проверок запускается:
перед комитом самим разработчиком
билдсистемой на ветке, даже если патч и не ломает билд/тесты, а всего лишь увеличивает количество warnings, то патч ещё нужно дорабатывать
почему я считаю, что мощный статический анализатор online не нужен:
считать все шаблоны и подстановки define в online это тяжело (тут думаю даже примеры приводить не нужно, достаточно по хабру поискать примеры кода которые не могут даже компиляторы переварить). сюда же можно записать, что изменение одного define для сборки может затронуть половину кода, в итоге мы кушаем все ядра и стараемся дать ответ максимально быстро или мы пересчитываем все на одном ядре к моменту, когда пользователь уже давно ушел с этого куска.
считать все пути выполнения кода и возможные значения входных переменных online тоже тяжело (нас не интересует разыменование указателя как таковое, везде ставить проверки устанешь, нас это может волновать, если анализатор скажет, что сюда в некоторых условиях может придти нулевой указатель и тогда все упадет)
в большинстве случаев online нужен с ограниченным функционалом, так как всё равно все сконцентрированы на том, чтобы реализовать работающую логику, пускай и без проверки граничных условий. дополнительные варнинги будут только сбивать с мысли, а уже когда видишь, что алгоритм вроде работает и начинаешь причесывать код к комиту, то тут и пора запускать анализатор и я как пользователь готов ждать и 5 минут (схожу за кофе) и 1 час (начну смотреть другой таск), пускай он в фоне работает и генерит вывод максимально корректно, а я по приходу посмотрю список «ошибок»
в моем понимании стоит разделять «базовые проверки» (когда мы в пределах блока кода или метода пытаемся что-то делать, та же копипаста в методах и одинаковые условия в if) и «мощный статический анализатор» (который анализирует весь control flow graph и указывает, что нам откуда-то что-то веселое приходит, а мы это совсем не ждем). первое уже везде в разном виде присутствует, а вот второе всегда было и останется offline, просто из-за того, что по мере того как фиксятся тормоза в одном месте и появляются ресурсные мощности, мы хотим добавить «ещё и вот эту проверочку».
clion подсвечивает базовые вещи, так же как и сама Idea (по работе java занимаюсь в основном)
когда же в clion дело доходит до плотной работы с шаблонами он на некоторых проектах просто зависает: поток анализа уходит в разворачивания шаблонов, ui ждет его, неважно сколько ты времени будешь ждать (ждал до 2х часов). работать в clion на том проекте невозможно, так как он зависает уже на навигации (к слову сказать раньше зависал уже через 2 минуты, сейчас и 5-10 может работать, но вызов анализа кода гарантированно вешает)
компиляторы работать с препроцессорами умеют в разы лучще, просто за счет того, что это одно из узких мест в компиляции c++ кода.
поэтому и стоит разделять:
1) простейшие подсказки со стороны ide работающие online
2) глубокий анализ offline, когда мы не связаны условиями к отзывчивости системы (не думаю, что кому-то понравится когда смена одного define поставит систему на колени переиндексацией)
да даже не знаю как описать, то что автор набросал:
1) hadoop (главная идея) — если данным долго идти к processing unit, то давайте вычислительные юниты придут к данным — объединяем data & compute nodes на одних машинках
2) YARN — изоляция ВЫЧИСЛИТЕЛЬНЫХ ресурсов (память/cpu/io), но в любом случае доступ к hdfs проходит зачастую по direct без использования сетевых сокетов. пытаться разворачивать свои приложения в ярне просто потому, что это модно или он якобы даёт хорошую изоляцию ресурсов глупо, уж лучше mesos смотреть в этом случае. Ярн использует cgroups, но namespaces не использует и не собирается, так как у него совсем другие задачи.
3) KSM — не, я конечно понимаю что openvz её не поддерживает (могу ошибаться, давно пинал), но lxc её умеет. её разрабатывали как раз для повышения плотности приложений и не только виртуалок.
4) www.projectserengeti.org — гипервизор предоставляет планировщику хадупа структуру кластера с учетом физической топологии (виртмашина-физмашина-стойка). неужели вы думаете, что vmware так просто отдаст этот рынок?
5) «Так, в случае Hadoop виртуализованный стек ввода/вывода состоит из HDFS, гостевой файловой системы, гостевого драйвера, виртуального устройства, интерпретатора формата образов, файловой системы хоста, драйвера хоста и, наконец, физического устройства» — raw девайсы отдавать уже не модно в виртуалки?
мне интересно другое:
для некоторых задач в которых применяются виртуалки приходится тюнить параметры ядра (зачастую сеть), есть задачи где требуются свои кастомные модули загружать в ядро, КАК в таких случаях себя поведут контейнеры?
в итоге статья сводится к КО: пихать везде виртуализацию глупо
но продолжается неправильно: давайте пихать везде контейнеры
а уж каким боком рассматривается yarn в качестве горизонтального масштабирования, учитывая до конца нерешенные проблемы с long running приложениями, я не понимаю, я бы еще понял если бы он в пример приводил mesos и mesosphere.com
Нет, я пытаюсь доказать, что чем больше тумана и оговорок в разных соглашениях MS, тем ей лучше.
Она никогда не пыталась вести игру в открытую, а политика почти с самого начала построена на запугивании и замалчивании (привет истории с Netscape и продвижению IE), ну и попытки влияния через третьи стороны, чтобы себя не светить (привет основному финансисту банкрота SCO на продолжения судов).
Я не считаю её корпорацией зла, хватает и более укуренных, но когда идет постоянное наведение тумана и запугивания, то не стоит пытаться казаться белыми и пушистыми, всё равно никто не поверит.
давайте уже полностью освещать состояние дел через пару лет после цитаты Horacio Gutierrez:
Список данных патентов не был публично обнародован, а Microsoft пообещала не выдвигать претензий против конечных пользователей Linux и использовала данный набор патентных нарушений для оказания давления на коммерческие структуры. В частности, были заключены патентные соглашения с такими компаниями, как Novell, Fuji-Xerox, Samsung и Xandros. С большинством из производителей оборудования подобные сделки совершались с обязательным подписанием договора о неразглашении, но огласку подобная практика получила после конфликта к компанией TomTom, отказавшейся заключить договор на кросс-лицензирование технологий Microsoft.
>> Вы ссылку не приложили, фантазии журналиста?
то есть компании заключают по очереди соглашения, но ни один человек в opensource не знает список патентов это фантазии? жаль, но это реальность
>> То есть номера патентов показывают, нагуглить их и обойти их никто не мешает. ЧТД.
показывают тем к кому наехали, все заплатили и сидели не раскрывая списка. список опубликовали только после того как в Китае начались разборки, до этого новости все были из разряда «Очередная компания Х подписала соглашение с Microsoft по лицензированию патентов для Android. Список не разглашается».
>> А можно с этого места поподробнее? Так и приходят, «дайте денег, но не скажем за что»? Как вообще патент может быть не опубликован?
Сама Microsoft предпочитает не раскрывать свои патенты, связанные с Android. В апреле представители компании сообщили в официальном блоге, что Microsoft принадлежит около 200 патентов, «необходимых для создания Android-смартфона».
нет, все немного мудрее: дайте денег, а то вас засудим, вот номера патентов, но вы не имеете право никому о них рассказывать, иначе засудим. В итоге сразу подписали htc, потом samsung и sony, дальше подтянулись производители помельче.
Все закончилось банально: попытались наехать на китайцев, китайцы послали подальше, а следом опубликовали весь список претензий.
p.s. за ссылки не на первоисточники извиняйте, первые что нагуглились.
В том что помимо софта есть понятие патента на алгоритм, о чем явно и говорят:
PATENTS.TXT
Microsoft Corporation and its affiliates («Microsoft») promise not to assert
any .NET Patents against you for making, using, selling, offering for sale,
importing, or distributing Covered Code, as part of either a .NET Runtime or
as part of any application designed to run on a .NET Runtime.
если вы использовали алгоритм из CoreCLR и CoreFX в своем продукте не заточенном под .net, то «Вам никто ничего не обещал».
p.s. погуглите за что дерут отчисления с android, один из основных патентов это алгоритм на поддержку fat32 для работы с флешками. В итоге MIT получается немного обрезанным.
неужто нас ожидает медленная java? =)
p.s. по асму там перед сохранением в массив пачка магии включая локи или это издержки дебаг версии?
курсы и по BigData и по ML
по крайней мере исходя из перечисленных тем обоих модулей я что-то не вижу чего-то эксклюзивного, за что можно заплатить 180к
конечно если компания готова заплатить, то слушателю как-то без разницы, даже 2млн не много, тут подходят пословицы «не свои, не жалко» и «нахаляву и уксус сладкий»
обычный минимальный набор базовых знаний, ключевое слово БАЗОВЫХ, по которым курсов и статей написано не просто много, а море, так как BigData & ML сейчас в тренде
если же ключевым является именно «курсов других крупных игроков рунета», то хочу вас расстроить, на этих курсах образование и закончится, так как все ключевые вещи идут на английском, а если знаешь english, то к чему отсылка на русских игроков?
p.s. Есть ли тут хоть кто либо, кто САМ платил, а не прошел по «бесплатной квоте» или за кого заплатили текущие работодатели?
Вы действительно не шутите когда в 2015 году предлагаете ручками писать map/reduce?
Первая часть по инструментарию легко и непринужденно решается hive/impala и обычным sql. К моменту когда первые ученики еще только будут заканчивать читать описание api,
в вилабаджио будут праздноватьвторая группа уже будет рисовать таблички и графикиПо машинному обучению уж насколько я недолюбливаю spark за их маркетинг, но конкретно в данном случае он может справиться и с первым заданием и со вторым в разы быстрее.
Так как ваши пункты по чистке нормально укладываются в pipeline и каждый из них будет отдельный map без смешивания логики, то спарк их прогонит за один проход. В хадупе или все в один map или пачку раз перезапускаем разные скрипты с сохранением промежуточных результатов, в любом случае не очень красиво.
Как результат у вас или datascienist закопается в инженерных нюансах как делать map/reduce, или если рассчитано на инженеров, то они в математики потом увязнут. Так на кого курс рассчитан?
1)
github.com/golang/go/issues/11485
On multi-gigabyte heaps, about half of our mark termination time (~5ms of ~10ms at 4GB) is spent in the loop over all spans in the _RootSpans case of markroot. We should fix this for 1.6.
то есть только финализаторы на 4GB не считая всего остального уже могут вызвать больше 10ms в STW
2) отсутсвует возможность compaction, следовательно привет фрагментированная куча, а для long running приложений эта проблема существует
и еще несколько пунктов, но пока я не видел ни одного, которого уже не сделали в других VM, пилятся вещи обязательные для любого CMS который не хочет быть совсем уж тормозным, поэтому и хочется узнать великий секрет почему на хипе в 64GB у них не будет пауз больше 10ms
Shenandoah не мейнстрим, но бесплатный, качай-собирай-используй
CMS в jvm vs CMS в GO и вторые заявляют, что у них сделано не как у всех, хотя по описанию у них отсутствуют даже многие необходимые вещи
отлично, открываем слайд 15:
1) нарисовано, что stw у нас 1 и 3 ms и там все стоит
2) между этими моментами у нас 25% это GC, 20% приложение, остальное… 55% assist. WTF??? почему про это нигде не сказано? ведь обещали 25% gc и остальное приложению.
3) красиво нарисовано расстояние между сборками, там можно хоть один столбик оставить и сказать что мы не мусорим, но какое поведение будет если столбики эти будут идти один за одним, что легко случается при активном создании-удалении объектов? приложение получит 20% ресурсов???
я понимаю, что управлять приходиться самому, просто «размер в 2.2 от активного хипа» когда у тебя хип на 1-2GB это нормально, но когда у тебя он на 64GB и ты чтобы не просесть используешь только половину, то это немного странно (да это один из пунктов критиков azul jvm, он требует удвоенного хипа).
p.s. я внимательно читаю и слайды и отдельные доклады и по go и по другим языкам, так как хочется следить за направлением развитий gc особенно для больших хипов, но пока в go я вижу стандартные маркетинговые заявления не подкрепленные ничем (был один глобальный сборщик STW и перешли на CMS и сразу вброс про то что мы победили паузы, на практике лишь сделать очевидный для всех небольшой шажок в правильном направлении)
1) вы отдаете 25% ресурсных мощностей под gc
2) вы отдаете под gc удвоенный хип
golang.org/s/go14gc
Tactically, we will use a hybrid stop the world (STW) / concurrent garbage collector (CGC). The STW piece will limit the amount of time goroutines are stopped to less than 10 milliseconds out of every 50 milliseconds. If the GC completes a cycle in this time frame, great. If not, the GC will transition into a concurrent GC for the remainder of the 50 millisecond block. This process will repeat until the GC cycle completes. As a practical matter if one has a 50 millisecond response quality of service (QOS) requirement one should expect to have 40 milliseconds in which to do mutator tasks. These numbers assume hardware equivalent to a generic $1000 desktop box running Linux.
>> Java секунды в порядке вещей
все ведь зависит в первую очередь от дефолтного поведения и версии jdk, в 8ке с этим заметно получше ;) а дальше начинается большой простор для творчества и флагов
1) pauseless gc в azule, то habrahabr.ru/post/148322 пачка магии с защитой страниц памяти от чтения, исправление указателей во время выполнения и остальная магия
2) проект Shenandoah (который пилит RedHat, но в 9ку он точно не войдет), то там использовали Brooks forwarding pointer (JEP 189). в нете находится несколько докладов от разработчиков.
базовые вещи в виде CMS коллектора уже давно есть, в 8ке сделали параллельную initialmark, что значительно ускорило данную фазу.
также g1 имеется, но там тоже есть нюансы в виде stw на эвакуации и разрастания rememberset таблиц, но он уже дефолтом будет в jkd9.
кроме как с pauseless этого достичь нельзя =) ну или как выше было сказано
один раз не пи...10ms не STW.>> но в 99.9% она будет ниже 10ms
а тут все зависит от приложения, чем больше потоков/горутин, тем больше у тебя точек root, тем по большему объему памяти это все размазано, то есть все больше random access в память нужно делать, который значительно медленней линейного сканирования.
>> Уверен, Хадсону об этом не нужно рассказывать.
Я же не говорю, что сомневаюсь в компетенции, но на данный момент нигде нету технических деталей почему это не скажется на производительности, а если вы ещё посмотрите на слайды 17 и 18, то там уже видно, что хоть 1.5 и обладает более предсказуемой производительностью для json, но на малых объемах хипа он сливает по скорости 1.4, а для splay на любых объемах немного медленней.
Именно потому что внимательно смотрел слайды и задал свой вопрос, так как бесплатный сыр бывает только в мышеловке.
конечно удачи в разработке, но и заявлять о великой победе супер gc тоже не стоит ;)
то есть 10мс это не STW, а просто постоим покурим?
наезды на java о том, что для работы с разными потоками ничего кроме локов не имеется тоже безосновательны, акка тут в помощь
>> Этот подход намеренно так сильно несоответствует большинству современных сборщиков мусора «энтерпрайз»-уровня
то есть CMS в jvm несуществует? там и STW на initialmark фазе и фаза remark которая проходит по вновь созданным объектам и тд
>> В трехцветном сборщике мусора, каждый объект может быть помечен, как белый, серый или чёрный, и мы рассматриваем кучу (heap) как граф связанных объектов. В начале каждого цикла GC все объекты белые. GC проходит всё корневые узлы (roots) графа, которые являются объектами, напрямую доступными программе — это глобальные переменные и переменные в стеке — и помечает их серыми. Затем GC выбирает серый объект, делает его чёрным, а затем сканирует его на наличие указателей и других объектов. Если скан обнаруживает указатель на белый объект, он делает его серым. Этот процесс повторяется, пока не останется серых объектов. В этот момент все белые объекты будут считаться недостижимыми и могут быть переиспользованы.
docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html смотрим секцию Incremental Mode и пытаемся найти отличия
если пихать везде write barrier, то и производительность можно просадить.
примеры сборок с ультранизкими паузами можно посмотреть у azul и java Shenandoah
поэтому резюмируя: ничего не понял как же они собираются достичь pauseless сборщика используя классический CMS
p.s. доклад и pdf смотрел, но там лишь рассказы как мы с блокирующего режима перешли на конкурентную сборку и все
почему я считаю, что мощный статический анализатор online не нужен:
в моем понимании стоит разделять «базовые проверки» (когда мы в пределах блока кода или метода пытаемся что-то делать, та же копипаста в методах и одинаковые условия в if) и «мощный статический анализатор» (который анализирует весь control flow graph и указывает, что нам откуда-то что-то веселое приходит, а мы это совсем не ждем). первое уже везде в разном виде присутствует, а вот второе всегда было и останется offline, просто из-за того, что по мере того как фиксятся тормоза в одном месте и появляются ресурсные мощности, мы хотим добавить «ещё и вот эту проверочку».
когда же в clion дело доходит до плотной работы с шаблонами он на некоторых проектах просто зависает: поток анализа уходит в разворачивания шаблонов, ui ждет его, неважно сколько ты времени будешь ждать (ждал до 2х часов). работать в clion на том проекте невозможно, так как он зависает уже на навигации (к слову сказать раньше зависал уже через 2 минуты, сейчас и 5-10 может работать, но вызов анализа кода гарантированно вешает)
компиляторы работать с препроцессорами умеют в разы лучще, просто за счет того, что это одно из узких мест в компиляции c++ кода.
поэтому и стоит разделять:
1) простейшие подсказки со стороны ide работающие online
2) глубокий анализ offline, когда мы не связаны условиями к отзывчивости системы (не думаю, что кому-то понравится когда смена одного define поставит систему на колени переиндексацией)
1) hadoop (главная идея) — если данным долго идти к processing unit, то давайте вычислительные юниты придут к данным — объединяем data & compute nodes на одних машинках
2) YARN — изоляция ВЫЧИСЛИТЕЛЬНЫХ ресурсов (память/cpu/io), но в любом случае доступ к hdfs проходит зачастую по direct без использования сетевых сокетов. пытаться разворачивать свои приложения в ярне просто потому, что это модно или он якобы даёт хорошую изоляцию ресурсов глупо, уж лучше mesos смотреть в этом случае. Ярн использует cgroups, но namespaces не использует и не собирается, так как у него совсем другие задачи.
3) KSM — не, я конечно понимаю что openvz её не поддерживает (могу ошибаться, давно пинал), но lxc её умеет. её разрабатывали как раз для повышения плотности приложений и не только виртуалок.
4) www.projectserengeti.org — гипервизор предоставляет планировщику хадупа структуру кластера с учетом физической топологии (виртмашина-физмашина-стойка). неужели вы думаете, что vmware так просто отдаст этот рынок?
5) «Так, в случае Hadoop виртуализованный стек ввода/вывода состоит из HDFS, гостевой файловой системы, гостевого драйвера, виртуального устройства, интерпретатора формата образов, файловой системы хоста, драйвера хоста и, наконец, физического устройства» — raw девайсы отдавать уже не модно в виртуалки?
мне интересно другое:
для некоторых задач в которых применяются виртуалки приходится тюнить параметры ядра (зачастую сеть), есть задачи где требуются свои кастомные модули загружать в ядро, КАК в таких случаях себя поведут контейнеры?
в итоге статья сводится к КО: пихать везде виртуализацию глупо
но продолжается неправильно: давайте пихать везде контейнеры
а уж каким боком рассматривается yarn в качестве горизонтального масштабирования, учитывая до конца нерешенные проблемы с long running приложениями, я не понимаю, я бы еще понял если бы он в пример приводил mesos и mesosphere.com
«создания 150 мВт ветроэлектростанции в Индиане» и «эта станция начнет производить 500000 мВт*ч энергии»
думаю как-то не сильно впечатляющие электростанции
Нет, я пытаюсь доказать, что чем больше тумана и оговорок в разных соглашениях MS, тем ей лучше.
Она никогда не пыталась вести игру в открытую, а политика почти с самого начала построена на запугивании и замалчивании (привет истории с Netscape и продвижению IE), ну и попытки влияния через третьи стороны, чтобы себя не светить (привет основному финансисту банкрота SCO на продолжения судов).
Я не считаю её корпорацией зла, хватает и более укуренных, но когда идет постоянное наведение тумана и запугивания, то не стоит пытаться казаться белыми и пушистыми, всё равно никто не поверит.
Список данных патентов не был публично обнародован, а Microsoft пообещала не выдвигать претензий против конечных пользователей Linux и использовала данный набор патентных нарушений для оказания давления на коммерческие структуры. В частности, были заключены патентные соглашения с такими компаниями, как Novell, Fuji-Xerox, Samsung и Xandros. С большинством из производителей оборудования подобные сделки совершались с обязательным подписанием договора о неразглашении, но огласку подобная практика получила после конфликта к компанией TomTom, отказавшейся заключить договор на кросс-лицензирование технологий Microsoft.
>> Вы ссылку не приложили, фантазии журналиста?
то есть компании заключают по очереди соглашения, но ни один человек в opensource не знает список патентов это фантазии? жаль, но это реальность
>> То есть номера патентов показывают, нагуглить их и обойти их никто не мешает. ЧТД.
показывают тем к кому наехали, все заплатили и сидели не раскрывая списка. список опубликовали только после того как в Китае начались разборки, до этого новости все были из разряда «Очередная компания Х подписала соглашение с Microsoft по лицензированию патентов для Android. Список не разглашается».
нет, все немного мудрее: дайте денег, а то вас засудим, вот номера патентов, но вы не имеете право никому о них рассказывать, иначе засудим. В итоге сразу подписали htc, потом samsung и sony, дальше подтянулись производители помельче.
Все закончилось банально: попытались наехать на китайцев, китайцы послали подальше, а следом опубликовали весь список претензий.
p.s. за ссылки не на первоисточники извиняйте, первые что нагуглились.
PATENTS.TXT
Microsoft Corporation and its affiliates («Microsoft») promise not to assert
any .NET Patents against you for making, using, selling, offering for sale,
importing, or distributing Covered Code, as part of either a .NET Runtime or
as part of any application designed to run on a .NET Runtime.
если вы использовали алгоритм из CoreCLR и CoreFX в своем продукте не заточенном под .net, то «Вам никто ничего не обещал».
p.s. погуглите за что дерут отчисления с android, один из основных патентов это алгоритм на поддержку fat32 для работы с флешками. В итоге MIT получается немного обрезанным.
там от хадупа только hdfs, ну и возможность при необходимости поверх yarn запускаться
вы наверное с Hive перепутали
а уж если говорить про аналитику, то вы скорее druid.io/, этакий distributed olap с заточенным под это дело хранилищем