Чтобы отметить эту дату, мы попросили Линуса поделиться скрытой историей создания Git, рассказать нам что он думает об этом проекте и о его влиянии на разработку программных продуктов. Вы найдёте его комментарии ниже в тексте. За этим интервью последует неделя Git, в которой каждый день мы будем рассматривать отдельные проекты, использующие эту систему контроля версий. Ожидайте истории разработки KVM, Qt, Drupal, Puppet, Wine и многие другие.
Почему ты создал Git?
Торвальдс: На самом деле, я никогда не хотел заниматься системой контроля версий (СКВ) и чувствовал что это была просто наименее интересная штука в компьютерном мире (возможно, за исключением баз данных ;^), и я страстно ненавидел все такие системы. Но тогда появился БитКипер (BK) и, действительно, изменил то, как я рассматривал контроль исходного кода. BK сделал правильно многие вещи. И возможность держать у себя локальную копию репозитория и распределённое слияние кода были хорошими штуками. Важная особенность распределённой модели контроля версий заключается в том, что она исключает одну из самых серьёзных проблем СКВ — политику того, кто может делать изменения. BK показал что ты можешь избежать это просто раздав всем репозиторий. Но BK имел и свои собственные проблемы; несколько технических решений приводили к проблемам (переименование было болезненным), но наихудшим был факт того, что поскольку BK не распространялся вместе с открытым кодом, то было и много людей, которые не хотели им пользоваться. Так что мы закончили тем, что было несколько основных разработчиков, использующих BK, который был бесплатен для использования в проектах с открытым кодом, но это никогда не стало общепринятым. Так что это (ВК) помогало в разработке ядра, но там всё равно оставались больные моменты.
Это пришло мне в голову тогда, когда Tridge (Andrew Tridgell) начал реверс-инжиниринг достаточно простого протокола BK, что было нарушением правил использования BK. Я потратил несколько недель (месяцев? Так я себя и чувствовал), пытаясь быть посредником между Tridge и Larry McVoy, но в итоге стало ясно, что это просто не работало. Итак, на каком-то этапе я просто решил, что я не могу больше продолжать использовать BK, но я также и не хочу возвращаться к худшим дням, которые были до появления BK. Грустно, что тогда были и другие инструменты для СКВ, которые в какой-то мере пытались использовать распределённую модель разработки, но ни один из них не работал хорошо в случае удалённого использования. У меня были свои требования к производительности, которые даже приближённо не могли быть удовлетворены тем, что было доступно; и я также волновался по поводу целостности кода и процесса разработки, так что я решил написать своё.
Как ты к этому подошёл? Ты писал его все выходные или только в обычное время?
Торвальдс: Эх. Вы, кстати, можете видеть как всё приняло форму в репозитории исходного кода Git, за исключением первого дня или что-то около того. День был потрачен на то, чтобы Git стал сам себя хостить так, чтобы можно было начать коммитить в Git используя Git. Поэтому первый день или что-то около того не присутствует в истории, но всё остальное — там. Основная работа была проведена, в основном, в течение дневного времени, но есть пара полуночных записей и пара — после двух часов ночи. Наиболее интересное, это то, как быстро это приняло форму. Самый первый коммит в дереве Git — это не много кода, но это делало основное — достаточное для того, чтобы закоммитить себя самого. Трюк был не столько в кодинге, сколько в том, чтобы понять как Git должен упорядочивать данные.
Я бы хотел подчеркнуть, что несмотря на то, что это было собрано в течение десяти дней или что-то вроде этого (в течение которых я сделал свой первый Git коммит в репозиторий ядра Линукса), это не было ни в какой мере сумасшедшим кодингом. Объём этого раннего кода достаточно мал, всё зависело от правильной реализации основных идей. И поэтому, я некоторое время «перемалывал» прежде чем весь проект был запущен. Я видел проблемы других. Я видел то, что я хотел избежать.
Выросло ли это (Git) до уровня твоих ожиданий? Как хорошо это (Git) работает по твоим оценкам? Есть ли какие-либо ограничения?
Торвальдс: Я очень доволен Git. Он работает исключительно хорошо с кодом ядра и по-прежнему следует моим ожиданиям. Что интересно, так это то, что он принял так много других проектов. К удивлению быстро, в конце концов. Существует много инертности в переключении от одних СКВ к другим; только взгляните как долго оставались в использовании CVS и даже RCS, но на каком-то этапе Git принял и их дела.
Как ты думаешь, почему это (Git) было так широко принят в использование?
Торвальдс: Я думаю, что многие люди были раздражены теми же самыми проблемами, которые заставили меня ненавидеть СКВ. И, хотя, было много проектов в попытке исправить одну или две мелких проблемы, которые выводили людей из себя, в действительности не существовало ничего такого как Git, что действительно помогло больше не брать больших проблем себе в голову. Даже когда люди не понимали насколько важна распределённая модель разработки (и много людей боролись с этим), то как только они осознавали, что это позволяет делать более лёгкие и надежные резервные копии и позволяет людям делать свои собственные репозитории без необходимости задумываться о политике разрешения записи в определённый репозиторий, они никогда не смотрели назад.
Будет ли Git существовать всегда или ты предугадываешь пересмотр СКВ в течение следующих десяти лет? Будешь ли ты одним из тех, кто напишет это?
Торвальдс: Нет, я не буду тем, кто это напишет. И, возможно, мы увидим что-то новое в течение десяти лет, но я гарантирую что, это будет нечто достаточно Git-подобное. Не в смысле что в Git всё правильно, но в том смысле что Git имеет основные возможности прямо внутри, которые другие СКВ ранее никогда не имели.
Без фальшивой скромности ;)
Почему Git работает так хорошо в Линуксе?
Торвальдс: Ну, Git был создан для нашей работы, потому он часть неё. Я уже упоминал распределённую модель много раз, но имеет смысл ещё раз вспомнить о ней. Но Git был также создан для того, чтобы быть достаточно эффективным для большого проекта как Линукс, и написан чтобы делать то, что люди считали сложной задачей перед появлением Git — потому что это те вещи, которые я делаю каждый день.
Просто для примера: понятие слияния рассматривалась как что-то очень болезненное и сложное во многих СКВ. Тебе бы приходилось планировать свои сливания, потому, что они были серьёзным делом. Это не устаивает меня, так как я, обычно, делаю десятки слияний в день когда нахожусь в во временном окне слияния, и даже при этом, рабочая нагрузка не должна быть в слиянии, а в тестировании кода. Слияние само по себе занимает пару секунд, гораздо больше занимает написание объяснения слияния.
Итак, Git был построен и написан для моих требований. Так и происходит.
Люди говорили что Git — только для супер умных людей. Даже Эндрю Мортон (Andrew Morton) говорил, что Git «Git спроектирован так, чтобы ты почувствовал себя ещё глупее чем раньше»2. Каков будет твой ответ на это?
Торвальдс: Ну я думаю, что так было сначала, но это больше не так. Есть несколько причин того, что люди так себя чувствуют, но я думаю что только одна причина осталась. Та, что осталась, очень проста: «это можно делать такими разными способами».
Можно делать много вещей при помощи Git, и многие из правил относительно того, что ты должен делать происходят не от технических ограничений, а оттого, что так работает неплохо, когда приходится взаимодействовать с другими людьми. Git является очень мощным набором инструментов, что может перегружать вначале, но это также значит, что ты можешь делать часто те же самые или похожие вещи разными путями и все они сработают. В общем, лучший способ изучить Git, вероятно, заключается в том, чтобы просто делать простые вещи и даже не смотреть на другие вещи до тех пор, пока ты не будешь уверенным в отношении основ.
Существуют несколько исторических причин для восприятия Git как сложной вещи. Одна из них — то, что это действительно было сложным. Те люди, которые начали использовать Git раньше всех для работы с ядром Линукса, действительно должны были научиться использовать достаточно непростой набор скриптов чтобы заставить всё работать. Все силы были направленны на то, чтобы заставить работать основную технологию и совсем немного — на то, чтобы сделать это легким или очевидным. Так и Git, естественно, имел репутацию которая предусматривала знание того, что ты делал ранее. Но это было, в основном, правдой только в течение первых шести месяцев или года.
Другая причина того, что люди считали, будто Git — сложная штука в том, что Git очень своеобразен. Есть люди, которые пользовались такими вещами как CVS на протяжении десятилетия или двух, и Git — не CVS. Даже не похожи. Разные концепции. Команды различаются. Git никогда не старалась выглядеть как CVS, как и наоборот. И, если ты пользовался CVS-подобной системой в течение длительного времени, то создаётся впечатление сложности и беспричинного отличия Git. Люди были оттолкнуты странной системой номеров версий. Почему номер версии Git «1.3.1», а не так как приятно сделано с увеличивающимися номерами в версиях CVS? Почему там (в Git) странный и страшный 40-символьный номер в шестнадцатеричной системе исчислений?
Но Git не был беспричинно другим. Эти отличия были нужны. Скорее всего, люди просто думают, что Git более сложен чем он есть на самом деле, просто потому, что они приходят с другим багажом опыта. Фон CVS уходит1. На настоящий момент, вероятно, есть множество программистов, которые никогда не использовали CVS в своей жизни и они могут посчитать то, как работает CVS, очень запутанным просто потому, что они изучили Git в первую очередь.
Могла бы скорость разработки ядра Линукса расти с существующей скоростью без Git? Почему?
Торвальдс: Ну, «без git» — конечно. Но это бы предусматривало то, что кто-то бы написал некий эквивалент Git: некую распределённую СКВ, которая была бы также эффективна, как и Git. Мы определённо нуждались в чём-то вроде Git.
Какое твое текущее мнение о GitHub?
Торвальдс: Github является исключительным ресурсом для хостинга; у меня совсем нет ничего против него. Жалобы, которые у меня были, заключались в том, что GitHub как платформа разработки — коммиты, пулл-реквесты, отслеживание истории проблем и так далее — не работает достаточно хорошо. Это даже не близко, не походит для чего-то вроде ядра Линукса. Слишком ограниченно.
Это частично от того, как ядро Линукса разработано, но частично и потому, что интерфейсы GitHub активно стимулируют к плохому поведению. Коммиты, сделанные на GitHub содержали комментарии этих коммитов и так далее, просто потому что веб-интерфейс на GitHub активно стимулировал к плохому поведению. Они исправили некоторые из этих вещей, так что, вероятно, работает лучше, но это никогда не будет подходящим для чего-то вроде ядра Линукса.
Какое самое интересное использование Git и/или GitHub ты встречал?
Торвальдс: Я очень рад, что он (Git) так облегчил запуск новых проектов. Хостинг проекта раньше доставлял много боли, но с появлением Git и GitHub сделать любой маленький проект стало так просто. Не важно, что за проект, важно то, что ты можешь сделать.
У тебя есть побочные проекты «в рукаве»? Какие-нибудь замечательные проекты, которые будут доминировать в разработке программного обеспечения на следующие годы?
Торвальдс: Ничего не планируется. Но я дам тебе знать если эти планы поменяются.
p.s.: советы и пожелания к переводу приветствуются с целью улучшения качества перевода.
1spmbt предложил альтернативный и не менее убедительный перевод этого предложения: «Прежний опыт работы с CVS уходит.»
2LampTester внизу упомянул лучший перевод этой фразы: «Git нарочно сделан так, чтобы вы почувствовали себя более тупым, чем есть».
Комментарии (44)
CaptainFlint
10.04.2015 21:31+21Такой перевод можно было и не выкладывать вовсе. Особенно эпично смотрятся всякие «это (BK)», «это (Git)». Даже в машинных переводах я такое лишь во времена Промта встречал…
Ezhyg
10.04.2015 21:48+6> с создателем — Линусом Торвальдс
либо склонять имя и фамилию, либо не склонять ни одно из слов
> и не какая другая система
не и ни, и всё такое
Ох, а это я ещё не начал читать…
С запятыми ужас.
Аббревиатуры со схожими символами из разных языков, надо привести к одному виду.
P.S. И, да, нет тут нормальной отправки комментариев об ошибках в личку, уж извините, я не виноват :(.
piva Автор
11.04.2015 01:141. исправил
2. исправил и исправил там, где смог найти
3. аббревиатуры привёл в порядок
С запятыми… я старался их привести в порядок, но если что, то подскажите.
Но в любом случае — спасибо.Ezhyg
11.04.2015 01:24+2Не за что.
Причина, почему я это делаю, хочу видеть «хороший текст», пусть даже он мне окажется не интересен или не нужен, как в данном случае :). Я себя неуютно чувствую, когда в первых же строках или абзацах «ашипки и ачепятки».
Причина почему я это делаю реже, чем хотелось бы — отсутствие возможности нормальной отсылки замечаний, поправок и прочего прямо во время чтения (Control+Enter и всё такое).
за сим заканчиваю «чятег в камментах»
starius
10.04.2015 22:52+1У меня от статьи сложилось впечатление, что Линус недоволен гитхабом и считает его неподходящим местом для проекта Linux. Так ли это? Дело в том, что репозиторий linux на гитхабе очень активен.
AMDmi3
11.04.2015 00:42+1Неподходящим местом для Linux != недоволен в целом. Во-первых, linux действительно большой проект, один из тех немногих для которых возможностей GitHub'а действительно мало. Во-вторых, для ядра сложились определённые традиции принятия изменений и code review, включающие использование maillist'ов, необходимость оформления патчей определённым образом diffstat и т.д. На мой взгляд это весьма субъективные претензии.
starius
11.04.2015 01:15Issues отключены. В общем, создается впечатление, что он не хочет растворять свою экосистему разработчиков ядра в экосистеме гитхаба. Сохраняются древние традиции, когда есть удобные аналоги на самом гитхабе. По моему мнению мимо проходящего, дело в привычках руководства проекта, так как на гит же перешли в итоге, значит теоретически ничто не мешает полностью перейти на сервисы гитхаба.
neolink
11.04.2015 09:30на 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 можно было бы согласиться но не факт что они бы не были завалены тоннами сообщений о том что не работает такое-то устройство и в итоге их бы пришлось всеравно отключитьAMDmi3
11.04.2015 15:57+2Не использовать issues действительно могут быть объективные причины. Всё-таки в крупном проекте понадобится и более мощная классификация, и связи между тасками, и поля для описания окружения, дедлайны и прочая. При этом независимо от требований иметь два параллельных issue трекера просто нельзя.
А вот pull request'ы на GH ничем, по сути, не отличаются от workflow в архаичных maillist'ах и даже в специализированном софте для code review, и отказываться от них — весьма недалёкое решение. Есть только одно оправдание этому — использование другой VCS (т.е. на github лежит только конвертированное зеркало). На практике (за исключением как раз таки ядра) я встречал отказы принимать PR только по этой причине, что в некоторой степени радует.neolink
11.04.2015 16:58не обязательно — в проекте могут быть очень жесткие правила code-review, в котором у каждого разработчика свои возможности, а также для некоторых модулей могут быть настроены более строги проверки — минимальное кол-во человек которые должны одобрить patch, даже ограничения на то кто могут быть эти люди и т.п.
AMDmi3
12.04.2015 03:20Ну если мы говорим о том же Linux, maillist'ы эти политики никак не обеспечивают, равно как и github. А так да — такое обеспечивается только отдельной системой code review. При этом, наверное, ничто не мешает участнику проекта принимать патчи через github, а потом уже проводить их через review как положено. В любом случае, такие жёсткие политики — нездоровое явление.
hell0w0rd
11.04.2015 00:46+2git по сути самостоятелен, гитхаб — это обертка вокруг, хуки и авторизация ssh-коннектов.
А недоволен Линус пулл-реквестами, почитайте 16 issue.starius
11.04.2015 01:11+2Это про переход в README к Markdown? Когда я первый раз увидел папку с файлами Linux, я подумал о том же: почему же README не в Markdown. Не знаете, есть ли где-нибудь официальное мнение Линуса по этому поводу?
piva Автор
11.04.2015 01:25я пытался вникнуть в то, чем его ГитХаб не утраивает. Но его ответ в этом интервью очень «обтекаемый».
В 2012 году он написал вот что о ГитХабе: github.com/torvalds/linux/pull/17#issuecomment-56546747
Был недоволен что гибхаб выбрасывает нужную информацию, адрес электронной почты, и тем как работает diffstat (бесполезен — его словами).
starius
11.04.2015 02:26+1Спасибо за ссылку — интересное чтение.
По-моему, разгадка примерно такая:
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).
spmbt
11.04.2015 04:26+2Веб-интерфейс Гитхаба — в самом деле, не приспособлен для коммита группы файлов и его можно рассматривать как самый простенький костыль, когда надо поправить 1 место или пулл-реквест в чужой репо, а скачивать весь репо не охота. (Хотя оценить пулл группы файлов там относительно комфортно, если оценивающий имеет под рукой ещё локальный проект.) Неизвестно, с чем Линус сравнивает интерфейс, но ясно, что он отзывается о веб-оболочке.
SerJook
11.04.2015 14:13mailing list это устаревший анахронизм
fshp
11.04.2015 14:46+1Недавно искал разработчиков BlueZ. И нашёл их лишь в рассылке. Причём там очень активные обсуждения, в день по 2-3 патча выкладывают. К выходу Android L готовились. Моё сообщение через 2 дня на первой странице рассылки уже не найти было.
starius
11.04.2015 16:02«устаревший анахронизм» — это тавтология, а mailing list — полезная штука, чтобы задавать вопросы и следить за новостями.
bubuq
11.04.2015 01:53+2«создан исключительно для того, чтобы заставить тебя почувствовать, что ты менее интеллектуальный, чем ты думал ранее»
О.М.Ф.Г.
Ну неужели ничего не покоробилось?
«expressly designed to make you feel less intelligent than you thought you were.» — «сделан специально, чтобы ты себя почувствовал тупее, чем есть», ну или как-то ещё, по-человеческиstarius
11.04.2015 02:30тупее, чем есть
В оригинале не «чем есть», а «чем ты думал раньше». Лучше косноязычно, но точно, чем красиво и вольно, по моему мнению. Искусство переводчика состоит в том, чтобы навести красоту, не растеряв точность.
LampTester
11.04.2015 19:02+1В оригинале таки «чем есть». Все оттого, что в английском языке действует правило согласования времен.
expressly designed to make you feel less intelligent than you thought you were
Designed (past) -> thought/were (past).
На русский переводится настоящим временем. Так что да, «нарочно сделан так, чтобы вы почувствовали себя более тупым, чем есть».starius
11.04.2015 19:30Очень интересный комментарий, спасибо!
Мне известно правило согласования времён и здесь оно имеет место между «you thought» и «you were». То есть «were» в прошедшем времени из-за того, что «thought» в прошедшем времени. Однако «you thought» относится не к «designed», а к «make you feel», которое вроде бы в настоящем времени, по моему мнению. Поправьте, если я ошибаюсь.LampTester
11.04.2015 19:38+1Я, разумеется, не коренной англичанин, но, как по мне, согласование времен имеет место между главным и придаточным предложениями или же, шире, между смысловыми группами. Здесь есть две смысловые группы — причина и следствие. Причина — что Git был разработан, следствие — что он деморализует людей. Разработан он был ранее, а деморализует до сих пор, и сейчас (now) тоже. Но, поскольку смысловая группа причины стоит в прошедшем времени, правило согласования времен вынуждает нас ставить в прошедшее и смысловую группу следствия.
neolink
11.04.2015 20:01+1весь спич Линуса и Эндрю — это 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
Эндрю: Спасибо всем пришедшим, большинство из вас вероятно уже слышали о Линусе Торвальдсе, а те, которые не слышали — это люди с Макинтошами на коленях. Это парень, который прется от издевательств над людьми. Его последняя выходка — создание СУВ, которая явно создана для того, чтобы вы почувствовали себя менее умными, чем до знакомства с ней. Спасибо, что снизошли до нас сегодня, Линус. Последние дни я получал письма от людей, вопрошающих: «Где Линус? Почему он не берет мою ветку? Он меня больше не любит… =(»
Newbilius
11.04.2015 10:43+6Я искренне считаю, что работа, сделнная посредственно, но принёсшая пользу — лучше, чем работа не сделанная совсем. Но в данном случае текст похож на результат работы автоматического переводчика, практически не редактировавшегося человеком. Если это не так, то автору порекомендую учить русский язык, т.к. с умением составлять на нём тексты явные проблемы.
Просто примеры:
начал реверсивную инженерию (достаточно просто) протокола BK
Что достаточно просто? Простая работа по разбору протокола? Сам протокол оказался простой? Не глядя в оригинал смысл не понять…
Я потратил несколько недель (месяцев? Так я себя и чувствовал),
«Я потратил несколько недель или даже месяцев»
ну или
«Я потратил несколько недель (а по ощущениям — даже месяцев)»
что действительно помогло больше не брать больших проблем себе в голову
«что позволило не задумываться о [больших] проблемах»
Без фальшивой скромности
«Без ложной скромности» же, ёлки-палки!
Итак, Git был построен и написан для моих требований. Так и происходит.
«Git разрабатывался под мои потребности, что в итоге и вышло» — тоже криво, надо в оригинал заглянуть будет, но всё-равно читабельней.
понятие сливания рассматривалась как что-то очень болезненное и сложное во многих СКВ
Видимо речь идёт о merg'ах. Но если уж очень не хочется использовать кальку с английского, то нужное нам слово — «слияние». Не «сливание».
У меня были свои требования к производительности, которые даже приближённо не могли быть удовлетворены тем, что было доступно
«У меня были свои требования к производительности, которые даже близко не покрывались доступными средствами.»
В общем, можно практически каждую вторую фразу брать и переводить с языка статьи на русский. Возвращаясь к своей начальной мысли, посредственно или даже плохо сделанная работа имеет право на существование, если полученный результат лучше, чем полное отсутствие результата. В данном же случае даже использование автоматического переводчика предпочтительнее. Т.е., польза сомнительна.
Ставлю минус статье, но карму автора не трогаю — надеюсь, он осознает свои ошибки и подтянет русский язык. Рекомендую следующий раз показать статью перед публикацией кому-нибудь из любящих чтение (и имеющих запас терпения) друзей, и делать так в последующие разы постоянно. Искренне желаю успехов в последующих начинаниях! :-)
stepik777
11.04.2015 22:34+1Вон он, первый коммит в истории git: Initial revision of «git», the information manager from hell
robux
12.04.2015 15:08Спасибо автору за перевод! Git — вещь! Линус — мужик!
Прочитал с большим удовольствием!
kapuletti
В последних абзацах перевод окончательно сломал мой мозг :)
piva Автор
А англоязычный ответ был лучше?
я могу, конечно, «причесать», но опасаюсь сделать его непохожим на исходник.
Lol4t0
Англоязычный был лучше
Например, it — значит не только это, а еще он, она, и т.д. Предпоследний ответ дословно звучит как
piva Автор
спасибо, я так, дейсвительно, лучше.
putnik
piva Автор
да, беда. исправил…
спасибо.
Lol4t0
ну это же просто коммент!
я бы еще теперь заменил облегчил на упростил, и написал «они» вместо «он (Git)». В контексте было бы понятно. А если подумать, то и еще улучшить что-нибудь можно
ploop
Естественно. Любой перевод можно вычитывать и править до бесконечности, сделав его сначала красивым, а потом преобразив слова автора. Тут главное вовремя остановиться :)
progchip666
Значит это заметил не только я. От прочтения статьи создаётся какое то странное ощущение, что качество перевода явно падает по мере приближения конца текста.
akuzmin
Этот перевод с самого начала не блистает дружелюбием к читателю.