Если верить интернетам, Hangouts больше не XMPP, а проприетарный протокол. С Jabber-собеседниками и альтернативными клиентами можно распрощаться. Дампать траффик пока сам не пытался, подтвердить\опровергнуть не могу.
Да, пришлось бы. Заодно с высокой вероятностью уместил бы эти 30 в осмысленные 5. В нескольких проектах, где я участв(-овал\-ую) есть простое правило, которое мне очень нравится — ты полностью в ответе за то, чтобы после слияния твоей ветке в масте осталась идеальная история коммитов. Какие бы изменения не приходили до этого, за итоговый результат всегда отвечаешь ты и тратишь столько времени на это, сколько потребуется.
«компилируются» == «компилируются и проходят все тесты», конечно же, на то он и Continuous Integration, чтобы предупредить вовремя.
По этой причине требование линеаризации обычно совмещается с требованиями на реформирование коммитов перед пушем, так, чтобы каждый отдельный коммит компилировался и был отдельным семантическим изменением. Можно даже заставить CI проверять дополнительно к каждому ушедшему в мастер коммиту ещё и все, что находятся между ним и последним протестированым (возможно, так и буду делать).
«Вас же не парит наличие во всяких Ruby/PHP собственных менеджеров пакетов?»
Ещё как парит. Установить какую-нибудь систему, написанную на Ruby (привет, redmine), не вдаваясь в детали, что такое есть этот самый Ruby — та ещё головная боль.
Я не пользуюсь Ubuntu и не знаю, как работает dpkg/apt. А вот в Arch Linux занимаюсь, в том числе, поддержкой некоторых пакетов и знаком с ситуацией не понаслышке. Т.к. это rolling-release дистрибутив, то ситуация, когда кому-то потребуется более старая версия софта \ библиотеки не редка, в Arch User Repository много таких пакетов. Самые обычные пакеты — собирают бинарники, устанавливают в систему, куда положено, имеют какую-то версию и т.п. Автор пакета берёт на себя все заботы по установке LD_PATH и иже с ним. Пользователь просто ставит его и пользуется двумя версиями одновременно, все довольны.
Если же речь о том, что вам хочется установить старую версия софта, для которого _нет_ пакета, то это не имеет отношения к проблеме dependency hell, т.к. точно такой же вопрос возникает, когда нужно установить новое свежее приложение, слишком малоизвестное для того, чтобы иметь пакет :)
Вот поэтому я больше не могу пользоваться дистрибутивами без аналога AUR.
Пакетный менеджер сам по себе никак не связан с распределением файлов по системе. Он просто знает о том, какие файлы принадлежат какому пакету и какие взаимоотношения между разными пакетами. То, что приложения потрошат по всей системе — это историческое наследие выраженное в en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Если господа из Ubuntu хотели совершить революцию, могли просто отказаться от FHS, сохранив нормальный пакетный менеджер с контролем зависимостей. В том же Arch я хоть сейчас могу наклепать PKGBUILD, который будет хранить все конфиги и приватные данные приложения в каком-нибудь /applications/, а бинарники устанавливать в /usr/bin и /usr/lib/
Нет, не привели. Как я уже отметил, мешать он может, только если конкретная реализация подобного реестра не очень хорошо спроектирована. А вот подход «всё своё ношу с собой» практически гарантирует мне 20 копий того же boost в системе.
Отнюдь. Ничего не знаю про работу apt, но в Arch это разруливается без особых проблем (хотя могло бы быть и лучше, конечно, но без ужаса, планируемого Ubuntu)
Отличный план, давайте откажемся от одной из лучших особенностей Linux-дистрибутивов и сделаем столь же убого, как в Win и Mac. Лучше бы договорились об ощем стандарте на формат пакетов между дистрибутивами, если силушку девать некуда.
К сожалению, из маркетинговых соображений было решено публиковать видеозаписи выступлений только по 2-3 в неделю. А жаль, там много очень вкусного, и не только специфичного для D. Когда будут опубликованы все — подготовлю краткий обзор с содержанием.
В какой-то момент был полузаброшен автором (eldar) и, насколько мне известно, так никем и не подобран. Наиболее активно подерживаются на данный момент GtkD и DWT.
А в этих областях Erlang ничем не примечателен.
2х ядер хватало для нативно компилируемых языков, речь идёт именно о том, что management overhead окружения заметно сказывается в таких условиях, пока вся сила системы многозадачности ещё не проявляется.
«всё ок» в том смысле, что она не падает до уровня интерпретируемых языков? О да. Но и только. Не так давно тестировал Erlang/Cowboy в рамках экспериментов с веб серверами — на 8 ядрах было топовым решением с однозначно лучшим latency. На 2х в серединке и вся стабильность latency сошла на нет. То есть уже ничем не лучше любого другого умеренно адекватного решения.
«With Hangouts, Singhal says Google had to make the difficult decision to drop the very „open“ XMPP standard that it helped pioneer.»
«компилируются» == «компилируются и проходят все тесты», конечно же, на то он и Continuous Integration, чтобы предупредить вовремя.
Ещё как парит. Установить какую-нибудь систему, написанную на Ruby (привет, redmine), не вдаваясь в детали, что такое есть этот самый Ruby — та ещё головная боль.
Если же речь о том, что вам хочется установить старую версия софта, для которого _нет_ пакета, то это не имеет отношения к проблеме dependency hell, т.к. точно такой же вопрос возникает, когда нужно установить новое свежее приложение, слишком малоизвестное для того, чтобы иметь пакет :)
Вот поэтому я больше не могу пользоваться дистрибутивами без аналога AUR.
Если господа из Ubuntu хотели совершить революцию, могли просто отказаться от FHS, сохранив нормальный пакетный менеджер с контролем зависимостей. В том же Arch я хоть сейчас могу наклепать PKGBUILD, который будет хранить все конфиги и приватные данные приложения в каком-нибудь /applications/, а бинарники устанавливать в /usr/bin и /usr/lib/
2х ядер хватало для нативно компилируемых языков, речь идёт именно о том, что management overhead окружения заметно сказывается в таких условиях, пока вся сила системы многозадачности ещё не проявляется.