Питер Келли уверен, что Facebook, как, впрочем, и другие социальные сети, предоставила людям новую доступную возможность найти себе случайного партнера на одну ночь.
Кстати очень скоро гугл выпускает телефон под своим брендом. Google Passion. Мне повезло взять его на тестирование и могу сказать что этот девайс очень-очень порадовал. Настолько порадовал что готов обменять свой iPhone на этот смартфон.
Сочетание мощного железа красивого дизайна и очень удобной платформы Android делает свое дело!
Ждите Google Passion на прилавках через пару недель.
4 самых главных пользователя gfs это (насколько я помню):
1) BigTable как основное хранилище данных в гугле
2) логи. Огромное количество логов со всех проектов. Gmail по моему год хранит логи на все действия пользователей.
3) Транзакционные данные для map-reduce. Когда 1 машина заканчивает свою часть вычеслений — она выкладывает данные в gfs. Другая машина эти данные использует как inut.
4) Gmail — почта пользователей. Насколько я знаю gmail #1 в потреблении дискового пространства среди google проектов.
Все проще — новая версия ставится сначала на 10% всех машин. И после некоторого времени, если нет критических ошибок, уже на все. Все развертываение длится (если мне память не изменяет) около 3х суток.
В Subversion довольно неплохой merge btw — он мержит все что сможет а что не сможет — добавляет маркеры.
Если вам станет легче от этого — то в Perforce мерж куда хуже, если он не может смержить файл; он вообще его не изменяет и пользователь должен смержить *все* сам.
Извиняюсь за небольшой оффтоп по поводу git. Видимо стоит описать свои мысли о гит в отдельной статье на habr.
> И на каждый патч выкладывать отдельный репозиторий?
Обычно поступают след. спопобом: 1 репозиторий 2 бранча. первый бранч т. н. origin. Это vanilla версия от автора в данном случае от Игоря Сысоева. В этой ветке будет то что и у Игоря в офиц. репозитории. Во второй ветке (master) вы ведете свою разработку. Переодически вытягиваете изменения из репозирория Игоря в свой origin и затем мержите в master.
> Да, я не хочу форкать, как минимум публично, nginx.
Вас видимо пугает слово форк. Это действительно было плохо с cvs/svn по причине того что там очень сложно синхронизировать (мержить) удаленные репозитории.
С git форк превратился из гадкого утенка в лебедя. Теперь форк репозитория это идеологически верный способ разработки. Особенно «нестандартных» фич, которые возможно не сразу войдут в главный репозиторий, но при этом вам хочется расшарить свою работу для других.
Для того чтобы смержить чейто удаленный репозиторий достаточно набрать
git merge git://repote-host/repo.git
Да кстати рекомендую вот эту лекцию Линуса Торвальдса (автора git). Предупреждаю сразу — это возможно полностью перевернет ваше представление о version control systems. www.youtube.com/watch?v=4XpnKHJAok8
BTW Другим будет проще получить ваш патч если он будет лежать в какой нить VCS. Git кстати идеально подходит. Вы можете выложить на github вашу патченную версию nginx.
Из крупных проектов GWT пользуются: Ads, Checkout, Orkut(некоторые подмодули).
Picasa — на чемто pythonообразном.
JsCompiler пользуются в gmail/maps/docs
Это реклама Facebook?
Установка/Update idea это такой постоянный мини-гемор на моей Ubuntu. Хотелось чтобы это было бы так же просто как и
sudo apt-get update
С другой стороны стандартный репозиторий это понижение уровня вхождения что влечет для вас большее количество пользователей.
Клавиатура — виртуальная. Проц 1Ггц.
Сочетание мощного железа красивого дизайна и очень удобной платформы Android делает свое дело!
Ждите Google Passion на прилавках через пару недель.
1) BigTable как основное хранилище данных в гугле
2) логи. Огромное количество логов со всех проектов. Gmail по моему год хранит логи на все действия пользователей.
3) Транзакционные данные для map-reduce. Когда 1 машина заканчивает свою часть вычеслений — она выкладывает данные в gfs. Другая машина эти данные использует как inut.
4) Gmail — почта пользователей. Насколько я знаю gmail #1 в потреблении дискового пространства среди google проектов.
Все проще — новая версия ставится сначала на 10% всех машин. И после некоторого времени, если нет критических ошибок, уже на все. Все развертываение длится (если мне память не изменяет) около 3х суток.
Если вам станет легче от этого — то в Perforce мерж куда хуже, если он не может смержить файл; он вообще его не изменяет и пользователь должен смержить *все* сам.
> И на каждый патч выкладывать отдельный репозиторий?
Обычно поступают след. спопобом: 1 репозиторий 2 бранча. первый бранч т. н. origin. Это vanilla версия от автора в данном случае от Игоря Сысоева. В этой ветке будет то что и у Игоря в офиц. репозитории. Во второй ветке (master) вы ведете свою разработку. Переодически вытягиваете изменения из репозирория Игоря в свой origin и затем мержите в master.
> Да, я не хочу форкать, как минимум публично, nginx.
Вас видимо пугает слово форк. Это действительно было плохо с cvs/svn по причине того что там очень сложно синхронизировать (мержить) удаленные репозитории.
С git форк превратился из гадкого утенка в лебедя. Теперь форк репозитория это идеологически верный способ разработки. Особенно «нестандартных» фич, которые возможно не сразу войдут в главный репозиторий, но при этом вам хочется расшарить свою работу для других.
Для того чтобы смержить чейто удаленный репозиторий достаточно набрать
git merge git://repote-host/repo.git
Вот к примеру проект rails имеет 347 публичных форков. github.com/rails/rails/network Ядро линукс — куда больше.
Да кстати рекомендую вот эту лекцию Линуса Торвальдса (автора git). Предупреждаю сразу — это возможно полностью перевернет ваше представление о version control systems. www.youtube.com/watch?v=4XpnKHJAok8
Есть lab feature которая позволяет менять порядок left-navbars
Лучше всего предлагать новые фичи здесь groups.google.com/group/gmail-labs-suggest-a-labs-feature/topics
Picasa — на чемто pythonообразном.
JsCompiler пользуются в gmail/maps/docs
Нет. Это можно сделать с помощью labels.
BTW Будем надеятся compiler будет выпущен в open-source, так что все смогут пользоваться им.