Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
В последних абзацах перевод окончательно сломал мой мозг :)
А англоязычный ответ был лучше?
я могу, конечно, «причесать», но опасаюсь сделать его непохожим на исходник.
я могу, конечно, «причесать», но опасаюсь сделать его непохожим на исходник.
Англоязычный был лучше
Например, it — значит не только это, а еще он, она, и т.д. Предпоследний ответ дословно звучит как
Например, it — значит не только это, а еще он, она, и т.д. Предпоследний ответ дословно звучит как
Я очень рад, что он (Git) так облегчил запуск новых проектов. Хостинг проекта раньше был доставлял много боли, но с появлением Git и GitHub сделать любой маленький проект стало так просто...
спасибо, я так, дейсвительно, лучше.
был доставлялЭто (цитата) действительно доставляет много боли.
Значит это заметил не только я. От прочтения статьи создаётся какое то странное ощущение, что качество перевода явно падает по мере приближения конца текста.
Этот перевод с самого начала не блистает дружелюбием к читателю.
Такой перевод можно было и не выкладывать вовсе. Особенно эпично смотрятся всякие «это (BK)», «это (Git)». Даже в машинных переводах я такое лишь во времена Промта встречал…
> с создателем — Линусом Торвальдс
либо склонять имя и фамилию, либо не склонять ни одно из слов
> и не какая другая система
не и ни, и всё такое
Ох, а это я ещё не начал читать…
С запятыми ужас.
Аббревиатуры со схожими символами из разных языков, надо привести к одному виду.
P.S. И, да, нет тут нормальной отправки комментариев об ошибках в личку, уж извините, я не виноват :(.
либо склонять имя и фамилию, либо не склонять ни одно из слов
> и не какая другая система
не и ни, и всё такое
Ох, а это я ещё не начал читать…
С запятыми ужас.
Аббревиатуры со схожими символами из разных языков, надо привести к одному виду.
P.S. И, да, нет тут нормальной отправки комментариев об ошибках в личку, уж извините, я не виноват :(.
1. исправил
2. исправил и исправил там, где смог найти
3. аббревиатуры привёл в порядок
С запятыми… я старался их привести в порядок, но если что, то подскажите.
Но в любом случае — спасибо.
2. исправил и исправил там, где смог найти
3. аббревиатуры привёл в порядок
С запятыми… я старался их привести в порядок, но если что, то подскажите.
Но в любом случае — спасибо.
Не за что.
Причина, почему я это делаю, хочу видеть «хороший текст», пусть даже он мне окажется не интересен или не нужен, как в данном случае :). Я себя неуютно чувствую, когда в первых же строках или абзацах «ашипки и ачепятки».
Причина почему я это делаю реже, чем хотелось бы — отсутствие возможности нормальной отсылки замечаний, поправок и прочего прямо во время чтения (Control+Enter и всё такое).
за сим заканчиваю «чятег в камментах»
Причина, почему я это делаю, хочу видеть «хороший текст», пусть даже он мне окажется не интересен или не нужен, как в данном случае :). Я себя неуютно чувствую, когда в первых же строках или абзацах «ашипки и ачепятки».
Причина почему я это делаю реже, чем хотелось бы — отсутствие возможности нормальной отсылки замечаний, поправок и прочего прямо во время чтения (Control+Enter и всё такое).
за сим заканчиваю «чятег в камментах»
У меня от статьи сложилось впечатление, что Линус недоволен гитхабом и считает его неподходящим местом для проекта Linux. Так ли это? Дело в том, что репозиторий linux на гитхабе очень активен.
Неподходящим местом для Linux != недоволен в целом. Во-первых, linux действительно большой проект, один из тех немногих для которых возможностей GitHub'а действительно мало. Во-вторых, для ядра сложились определённые традиции принятия изменений и code review, включающие использование maillist'ов, необходимость оформления патчей определённым образом diffstat и т.д. На мой взгляд это весьма субъективные претензии.
Issues отключены. В общем, создается впечатление, что он не хочет растворять свою экосистему разработчиков ядра в экосистеме гитхаба. Сохраняются древние традиции, когда есть удобные аналоги на самом гитхабе. По моему мнению мимо проходящего, дело в привычках руководства проекта, так как на гит же перешли в итоге, значит теоретически ничто не мешает полностью перейти на сервисы гитхаба.
на git перешли потому что хлебнули свободы DVCS, а систему которая это обеспечивала (BitKeeper) использовать более не представлялось возможным. (подробнее lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks)
Linux далеко не единственный проект на GitHub который не использует их Pull Requests. Про Issues можно было бы согласиться но не факт что они бы не были завалены тоннами сообщений о том что не работает такое-то устройство и в итоге их бы пришлось всеравно отключить
Linux далеко не единственный проект на GitHub который не использует их Pull Requests. Про Issues можно было бы согласиться но не факт что они бы не были завалены тоннами сообщений о том что не работает такое-то устройство и в итоге их бы пришлось всеравно отключить
Не использовать issues действительно могут быть объективные причины. Всё-таки в крупном проекте понадобится и более мощная классификация, и связи между тасками, и поля для описания окружения, дедлайны и прочая. При этом независимо от требований иметь два параллельных issue трекера просто нельзя.
А вот pull request'ы на GH ничем, по сути, не отличаются от workflow в архаичных maillist'ах и даже в специализированном софте для code review, и отказываться от них — весьма недалёкое решение. Есть только одно оправдание этому — использование другой VCS (т.е. на github лежит только конвертированное зеркало). На практике (за исключением как раз таки ядра) я встречал отказы принимать PR только по этой причине, что в некоторой степени радует.
А вот pull request'ы на GH ничем, по сути, не отличаются от workflow в архаичных maillist'ах и даже в специализированном софте для code review, и отказываться от них — весьма недалёкое решение. Есть только одно оправдание этому — использование другой VCS (т.е. на github лежит только конвертированное зеркало). На практике (за исключением как раз таки ядра) я встречал отказы принимать PR только по этой причине, что в некоторой степени радует.
не обязательно — в проекте могут быть очень жесткие правила code-review, в котором у каждого разработчика свои возможности, а также для некоторых модулей могут быть настроены более строги проверки — минимальное кол-во человек которые должны одобрить patch, даже ограничения на то кто могут быть эти люди и т.п.
Ну если мы говорим о том же Linux, maillist'ы эти политики никак не обеспечивают, равно как и github. А так да — такое обеспечивается только отдельной системой code review. При этом, наверное, ничто не мешает участнику проекта принимать патчи через github, а потом уже проводить их через review как положено. В любом случае, такие жёсткие политики — нездоровое явление.
git по сути самостоятелен, гитхаб — это обертка вокруг, хуки и авторизация ssh-коннектов.
А недоволен Линус пулл-реквестами, почитайте 16 issue.
А недоволен Линус пулл-реквестами, почитайте 16 issue.
Это про переход в README к Markdown? Когда я первый раз увидел папку с файлами Linux, я подумал о том же: почему же README не в Markdown. Не знаете, есть ли где-нибудь официальное мнение Линуса по этому поводу?
я пытался вникнуть в то, чем его ГитХаб не утраивает. Но его ответ в этом интервью очень «обтекаемый».
В 2012 году он написал вот что о ГитХабе: github.com/torvalds/linux/pull/17#issuecomment-56546747
Был недоволен что гибхаб выбрасывает нужную информацию, адрес электронной почты, и тем как работает diffstat (бесполезен — его словами).
В 2012 году он написал вот что о ГитХабе: github.com/torvalds/linux/pull/17#issuecomment-56546747
Был недоволен что гибхаб выбрасывает нужную информацию, адрес электронной почты, и тем как работает diffstat (бесполезен — его словами).
Спасибо за ссылку — интересное чтение.
По-моему, разгадка примерно такая:
По-моему, разгадка примерно такая:
Obviously that’s not how you do things. You are an email person, using mailing lists as the main (if not only) way to discuss and propose changes to your projects. And I think that is perfectly fine, especially looking at how well it works with your projects.То есть, он просто привык к email и не привык к веб-интерфейсу, вот и высказывается. (Все комментарии к этой дискуссии он писал, отвечая на письма. Отсюда и жалобы на неполноту информации и на переносы строк.) Печально, потому что это искусственное ограничение, по моему мнению. Если пулл-реквест оформлен по правилам, то, если его подают через гитхаб, а не через список рассылки, почему его не принять? Хотя он прав в том, что веб-интерфейс гитхаба действительно слишком либерален по отношению к длине строк и формату описания коммита и пулл-реквеста. Но это уже ведь не его проблема, как мне следить за длиной строк.
But I don’t think that makes pull requests on GitHub inferior. They are different, yes, they require a different workflow, but that workflow works extremely well for many projects, especially those that are not using other means for communication (like mailing lists).
Веб-интерфейс Гитхаба — в самом деле, не приспособлен для коммита группы файлов и его можно рассматривать как самый простенький костыль, когда надо поправить 1 место или пулл-реквест в чужой репо, а скачивать весь репо не охота. (Хотя оценить пулл группы файлов там относительно комфортно, если оценивающий имеет под рукой ещё локальный проект.) Неизвестно, с чем Линус сравнивает интерфейс, но ясно, что он отзывается о веб-оболочке.
mailing list это устаревший анахронизм
Недавно искал разработчиков BlueZ. И нашёл их лишь в рассылке. Причём там очень активные обсуждения, в день по 2-3 патча выкладывают. К выходу Android L готовились. Моё сообщение через 2 дня на первой странице рассылки уже не найти было.
«устаревший анахронизм» — это тавтология, а mailing list — полезная штука, чтобы задавать вопросы и следить за новостями.
«создан исключительно для того, чтобы заставить тебя почувствовать, что ты менее интеллектуальный, чем ты думал ранее»О.М.Ф.Г.
Ну неужели ничего не покоробилось?
«expressly designed to make you feel less intelligent than you thought you were.» — «сделан специально, чтобы ты себя почувствовал тупее, чем есть», ну или как-то ещё, по-человечески
тупее, чем естьВ оригинале не «чем есть», а «чем ты думал раньше». Лучше косноязычно, но точно, чем красиво и вольно, по моему мнению. Искусство переводчика состоит в том, чтобы навести красоту, не растеряв точность.
«Git спроектирован так, чтобы ты почувствовал себя ещё глупее чем раньше»
В оригинале таки «чем есть». Все оттого, что в английском языке действует правило согласования времен.
Designed (past) -> thought/were (past).
На русский переводится настоящим временем. Так что да, «нарочно сделан так, чтобы вы почувствовали себя более тупым, чем есть».
expressly designed to make you feel less intelligent than you thought you were
Designed (past) -> thought/were (past).
На русский переводится настоящим временем. Так что да, «нарочно сделан так, чтобы вы почувствовали себя более тупым, чем есть».
Очень интересный комментарий, спасибо!
Мне известно правило согласования времён и здесь оно имеет место между «you thought» и «you were». То есть «were» в прошедшем времени из-за того, что «thought» в прошедшем времени. Однако «you thought» относится не к «designed», а к «make you feel», которое вроде бы в настоящем времени, по моему мнению. Поправьте, если я ошибаюсь.
Мне известно правило согласования времён и здесь оно имеет место между «you thought» и «you were». То есть «were» в прошедшем времени из-за того, что «thought» в прошедшем времени. Однако «you thought» относится не к «designed», а к «make you feel», которое вроде бы в настоящем времени, по моему мнению. Поправьте, если я ошибаюсь.
Я, разумеется, не коренной англичанин, но, как по мне, согласование времен имеет место между главным и придаточным предложениями или же, шире, между смысловыми группами. Здесь есть две смысловые группы — причина и следствие. Причина — что Git был разработан, следствие — что он деморализует людей. Разработан он был ранее, а деморализует до сих пор, и сейчас (now) тоже. Но, поскольку смысловая группа причины стоит в прошедшем времени, правило согласования времен вынуждает нас ставить в прошедшее и смысловую группу следствия.
весь спич Линуса и Эндрю — это 2007 год, и он неплохо переведен здесь:
lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks
Эндрю: Спасибо всем пришедшим, большинство из вас вероятно уже слышали о Линусе Торвальдсе, а те, которые не слышали — это люди с Макинтошами на коленях. Это парень, который прется от издевательств над людьми. Его последняя выходка — создание СУВ, которая явно создана для того, чтобы вы почувствовали себя менее умными, чем до знакомства с ней. Спасибо, что снизошли до нас сегодня, Линус. Последние дни я получал письма от людей, вопрошающих: «Где Линус? Почему он не берет мою ветку? Он меня больше не любит… =(»
lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks
Эндрю: Спасибо всем пришедшим, большинство из вас вероятно уже слышали о Линусе Торвальдсе, а те, которые не слышали — это люди с Макинтошами на коленях. Это парень, который прется от издевательств над людьми. Его последняя выходка — создание СУВ, которая явно создана для того, чтобы вы почувствовали себя менее умными, чем до знакомства с ней. Спасибо, что снизошли до нас сегодня, Линус. Последние дни я получал письма от людей, вопрошающих: «Где Линус? Почему он не берет мою ветку? Он меня больше не любит… =(»
нет не чего
нИчего
Я искренне считаю, что работа, сделнная посредственно, но принёсшая пользу — лучше, чем работа не сделанная совсем. Но в данном случае текст похож на результат работы автоматического переводчика, практически не редактировавшегося человеком. Если это не так, то автору порекомендую учить русский язык, т.к. с умением составлять на нём тексты явные проблемы.
Просто примеры:
Что достаточно просто? Простая работа по разбору протокола? Сам протокол оказался простой? Не глядя в оригинал смысл не понять…
«Я потратил несколько недель или даже месяцев»
ну или
«Я потратил несколько недель (а по ощущениям — даже месяцев)»
«что позволило не задумываться о [больших] проблемах»
«Без ложной скромности» же, ёлки-палки!
«Git разрабатывался под мои потребности, что в итоге и вышло» — тоже криво, надо в оригинал заглянуть будет, но всё-равно читабельней.
Видимо речь идёт о merg'ах. Но если уж очень не хочется использовать кальку с английского, то нужное нам слово — «слияние». Не «сливание».
«У меня были свои требования к производительности, которые даже близко не покрывались доступными средствами.»
В общем, можно практически каждую вторую фразу брать и переводить с языка статьи на русский. Возвращаясь к своей начальной мысли, посредственно или даже плохо сделанная работа имеет право на существование, если полученный результат лучше, чем полное отсутствие результата. В данном же случае даже использование автоматического переводчика предпочтительнее. Т.е., польза сомнительна.
Ставлю минус статье, но карму автора не трогаю — надеюсь, он осознает свои ошибки и подтянет русский язык. Рекомендую следующий раз показать статью перед публикацией кому-нибудь из любящих чтение (и имеющих запас терпения) друзей, и делать так в последующие разы постоянно. Искренне желаю успехов в последующих начинаниях! :-)
Просто примеры:
начал реверсивную инженерию (достаточно просто) протокола BK
Что достаточно просто? Простая работа по разбору протокола? Сам протокол оказался простой? Не глядя в оригинал смысл не понять…
Я потратил несколько недель (месяцев? Так я себя и чувствовал),
«Я потратил несколько недель или даже месяцев»
ну или
«Я потратил несколько недель (а по ощущениям — даже месяцев)»
что действительно помогло больше не брать больших проблем себе в голову
«что позволило не задумываться о [больших] проблемах»
Без фальшивой скромности
«Без ложной скромности» же, ёлки-палки!
Итак, Git был построен и написан для моих требований. Так и происходит.
«Git разрабатывался под мои потребности, что в итоге и вышло» — тоже криво, надо в оригинал заглянуть будет, но всё-равно читабельней.
понятие сливания рассматривалась как что-то очень болезненное и сложное во многих СКВ
Видимо речь идёт о merg'ах. Но если уж очень не хочется использовать кальку с английского, то нужное нам слово — «слияние». Не «сливание».
У меня были свои требования к производительности, которые даже приближённо не могли быть удовлетворены тем, что было доступно
«У меня были свои требования к производительности, которые даже близко не покрывались доступными средствами.»
В общем, можно практически каждую вторую фразу брать и переводить с языка статьи на русский. Возвращаясь к своей начальной мысли, посредственно или даже плохо сделанная работа имеет право на существование, если полученный результат лучше, чем полное отсутствие результата. В данном же случае даже использование автоматического переводчика предпочтительнее. Т.е., польза сомнительна.
Ставлю минус статье, но карму автора не трогаю — надеюсь, он осознает свои ошибки и подтянет русский язык. Рекомендую следующий раз показать статью перед публикацией кому-нибудь из любящих чтение (и имеющих запас терпения) друзей, и делать так в последующие разы постоянно. Искренне желаю успехов в последующих начинаниях! :-)
Это(перевод) написан в стиле промта
Спасибо автору за перевод! Git — вещь! Линус — мужик!
Прочитал с большим удовольствием!
Прочитал с большим удовольствием!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Десять лет Git: интервью с создателем — Линус Торвальдс