На мой взгляд интересная заметка автора библиотеки SObjectizer о SVN, нелюбви к нему и степени владения инструментом тех, кто его не любит: http://eao197.blogspot.ru/2015/09/progflame-svn.html
Случаев, когда реально терялся компилятор или ОС я что-то припомнить не могу. С библиотеками же такое происходит и люди видимо с этим сталкивались. Даже если теряется не сама библиотека, может исчезнуть из апстрима ее старая версия, которая для тестов старой версии ПО потребуется или еще для чего-то подобного.
> Народ использует систему версионного контроля как резервное хранилище.
А почему версии библиотек не должны отслеживаться системами версионного контроля?
Наверное даже спрошу так, почему версия библиотеки в Вашем понимании — это только строка вида 1.2.3?
Вы никогда не патчили библиотеки, не бекпортировали в них изменения из аптрима без обновления всей библиотеки для сохранения ABI/API? По всем этим причинам для меня версии библиотек это не только цифры, но и весь ее код, который должен как минимум логически храниться или быть доступным в репозитории проекта.
Люди готовые работать кем угодно от безысходности вряд ли быстро уйдут из компании даже в случае постоянных переработок и перегрузок. Думаю, это была одна из решающих причин найма этой девушки, а не круглая сумма лишь позволила увидеть эту безысходность…
Почему такой вывод. Формулировка «столько мне требуется для оплаты и проживания в месяц», говорит о том, что цель только прожить этот месяц. Из ответа не видно желания копить деньги на какую либо глобальную цель (например, на отпуск или хобби) или хотя бы на создание собственной финансовой подушки безопасности (куда могла бы пойти сумма округления).
> Ну судя по вашей логике, нужно все сразу.
Ну раз все сразу, то в случае одновременного исчезновения Intel, Microsoft, GNU FSF и Apple, я думаю мне нужно будет искать другую отрасль (скорее всего земледелие), а не думать о том, что будет с моими проектами.
С библиотеками же все проще. Наглядный пример такого исчезновения я Вам привел (с гитхаба кстати).
> А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
И это тоже есть. Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории. Да, можно довести до одного клика, но в условиях множественных окружений это не имеет смысла на машине разработчика, а на билд-сервере все собирается в один клик на всех окружениях, там это имеет смысл.
> У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
У меня очень ограниченный composer, так как Web-интерфейсы занимают меньшую часть моего времени.
Но даже в случае с composer я предпочитаю не перерабатывать сам и упрощать сервисные задачи. Лишние N Мб зависимостей в репозитории меня при этом не пугают, тем более, что их обновления идут в отдельных коммитах и не замусоривают историю.
> Просто вы не улавливаете мою иронию.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
> При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
> Что мешает сложить туда же ваши зависимости?
Удобство использования. Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия.
Скажите, пожалуйста, Вы читать умеете?
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере. Прочитайте уже перевод слово репозиторий, чтобы перестать ассоциировать его исключительно с системами управления версиями.
Еще раз повторюсь, что в проект имеет смысл складывать сильно связанные компоненты. Слабо связанные имеет смысл хранить, но не в проекте. Тот факт, что свой проект, который я сейчас подразумеваю собирается более чем в 30 окружениях, то каждое отдельное окружение слабо связано с проектом.
Библиотека же может использоваться только конкретной протестированной версии, так как ABI-совместимость и все такое — это сильно связанная компонента.
> github.com/pathscale?
Там есть исходники компилятора, который они выкладывали?
Оно было здесь: http://www.path64.org/ и https://github.com/path64, но исчезло и сылки с path64.org теперь ведут в никуда (например, github.com/path64/compiler).
Исчезновение библиотек я видел (например, поищите исходники PathScale и библиотек, которые они выкладывали на гитхаб и которые потом исчезли). Исчезновение всего линукса слишком маловероятно. Это во первых.
Во вторых, мой софт использует конкретную версию конкретной библиотеки, ее имеет смысл положить рядом. Компилируется же он в трех десятках окружений гарантированно и я не знаю в скольки еще линуксах скорее всего. Их не имеет смысла держать совсем рядом, при этом, как я уже писал выше, все компоненты окружений и сборки сборочных виртуальных машин аккуратно сложены в отдельном каталоге на файловом сервере.
Так в том то и дело, что храню!
Не путайте техническое разбиение инфраструктуры на репозитории, сабмодули и прочее с организационной стороной. С организационной точки зрения в моем репозитории есть и компиляторы.
Ох! Конечно же все, что написано во втором абзаце моего предыдущего комментария относится только к зависимостям вида библиотеки и подобное (в папке vendor традиционно хранятся библиотеки).
Изначально в статье был вопрос:
> Стоит ли хранить содержимое папки vendor в наших репозиториях?
Для меня наш репозиторий — это все то, что находится под моим управлением, включая условные svn.company.com, git.company.com, files.company.com, pkg.company.com и другие варианты. Гитхаб и репозитории вендоров по этому определению не наши.
Да, в дальнейшем было уточнение, что вопрос следует понимать как «прямо в репозитории с проектом».
Если брать этот вопрос, то на него однозначно я ответить не могу, однако, склоняюсь к мысли, что можно и хранить, так как единственный контраргумент по сути — это размер репозитория, но для меня это не критично. А на девелоперскую и сборочную машину все равно весь этот объем тащить надо для сборки.
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Почему не храним?
Например, у меня в отдельном репозитории лежат и iso-образы сборочной ОС, и клоны репозитория, и скрипты ее автоустановки и автонастройки, чтобы в любой момент времени нужные виртуальные машины могли быть автоматически пересобраны даже если билд-кластер умрет полностью.
Только вот этот репозиторий не git или svn, а отдельный каталог на файловом сервере.
Да, это занимает дополнительное место, но все это дает мне гарантированную воспроизводимость окружения сборки и всех зависимостей (зависимости проектов я тоже храню у себя), что для меня важно.
Ну и независимость от внешних репозиториев в моменты сборки тоже неплохой бонус, а если сборка всегда проводится на чистых машинах, то для загрузчиков зависимостей нужно либо кэши городить, либо каждый билд тащить из интернета сотни мегабайт библиотек.
Я думаю, что случаях, когда любой инженер или ученый дал бы примерно одинаковый ответ Борис Евсеевич думал скорее всего аналогичным образом.
Ситуация в которой с появлением новых знаний старые работающие решения признаются либо неправильными(неоптимальными), либо ненадежными является на столько типичной, что мне странно, что она для кого-то может быть неожиданной. Для этого не надо быть медиумом. Достаточно быть инженером.
> «Если бы сейчас положили на полигоне корабль «Восток» и все современные главные, сели бы и посмотрели на него, никто не проголосовал бы пускать такой ненадёжный корабль…
Спросите любого конструктора любой техники сложнее утюга и они ответят Вам точно так-же. В этой части цитаты нет никакого откровения для инженеров.
Легко видеть правильный путь, когда результат достигнут, но чтобы его достичь придется пройти через ошибки и работу с недостатком информации. Черток это понимал, что в вашей цитате подтверждается фразой «Получил огромный опыт и понял, как сильно мы рисковали», а Вы к сожалению нет…
Позвольте в свою очередь не согласиться с Вами.
Вы путаете проблему старта в предметной области и дальнейшее развитие в оной.
Старт отличается тем, что Вы или абстрактный человек имеет только вопросы, но не знает даже примерных направлений куда копать, в связи с этим выучиться самостоятельно можно, но из-за частого и не всегда верного выбора направления в слепую «очень много времени будет потрачено просто зря». Наличие же кого-нибудь, кто будет задавать направление этого поиска ответов сократить время обучения в разы.
В дальнейшем же развитии специалиста в ответ на большинство вызовов он сможет сам задавать себе направления поиска, так как его знания помогут это направление определить. Думаю, не сильно ошибусь, если скажу, что в разработке не так много задач, в которых совершенно непонятно с какой стороны пробовать начинать искать решение.
+1 к Андромеде.
Правда, огорчает тот факт, что этот сериал пережил смену сценаристов и стройность/обоснованность сюжета была принесена в жертву ради понижения порога вхождения в сериал зрителей с любой серии.
> Краткая суть — реальные условия эксплуатации двигателей отличаются от лабораторных. Ну кто бы мог подумать, а?
Если про мой комментарий, то совершенно нет.
Краткая суть моего комментария — вред нужно оценивать комплексно, а не брать для сравнения двух технологий в первой фактор, где она безусловно проигрывает, а во второй — где она безусловно выигрывает и на этом основании говорить что вторая лучше.
Если же в общем, то да, полностью согласен. Выбросы в реальных условиях эксплуатации по сути не регламентированы.
> смотришь на шлейф дыма за соседним грузовиком
Так это же очевидно. Грузоперевозки — это большие деньги и лоббирование. Кто пойдет против тех, кто и ответить может?
Не путайте интересы политиков, которым нужно заставить средний класс что-то делать и реальные потребности среднего класса. Я прекрасно понимаю и то и то, а еще и психологию толпы, которую в данном случае нещадно эксплуатируют.
Что же касается сравнительных характеристик, пусть это останется на Вашей совести…
> Правда, потом оказалось, что с уловителем частиц машина заводится плохо, и его лучше снять, к тому же, дизель выдаёт в несколько раз больше оксидов азота, чем бензин. Оксиды азота, в частности, пагубно влияют на людей с респираторными заболеваниями. Дизельные двигатели сложнее бензиновых и сильно дороже в обслуживании.
Это манипулирование фактами и как следствие суммарно получилась ложь практически от первого и до последнего слова.
1) ПДК на выбросы частиц сажи для дизелей был всегда, а для бензиновых появился только в ЕВРО-5. Более того, эта норма для бензиновых двигателей точно такая-же, как и для дизелей.
Кстати, в бензиновых двигателях тоже ставят нейтрализаторы и т.д., которые при неисправности могут усложнять запуск двигателя и которые тоже можно снять, но об этом почему-то молчат.
2) Да, дизель выдает больше оксидов азота, так как в его цилиндрах значительно жарче, но при этом выдает в разы меньше угарного газа, углеводородов, летучей органики и т.д.
К сожалению, ни одной статьи на тему, что из этого В КОМПЛЕКСЕ вреднее для экологии я не видел. Везде выдергивают из контекста один параметр и изучают только его влияние.
В очередной раз прошу сообщество подсказать, есть ли исследования опубликованные в серьезных изданиях о комплексном вреде выхлопа разных типов двигателей. Мне, к сожалению, таких найти не удалось. Может быть я плохо или не там искал?
3) Современный дизель компоновочно не сложнее бензинового с непосредственным впрыском, Больше различий, в том числе в весе, из-за повышенных требований к прочности изделия. Ну и за аккумулятором приходится следить.
Что-же касается обслуживания, то за время гарантии разница в цене выйдет в несколько сотен долларов, которые будут полностью компенсированы снижением операционных расходов (мой пепелац с массой 2-2,5т потребляет от 8 до 11 л/100км, у бензиновых пепелацев этой-же марки расход начинается литров с 12, а заканчивается под 20, при этом требуют они бензин, который в наших краях дороже солярки).
> Уже в 2014 году началась кампания по избавлению Европы от дизельных автомобилей – вероятно, в пользу велосипедов…
А это правда. Только причина скорее всего в очередном лоббировании обновления автопарка. В свое время переход на дизеля этому хорошо поспособствовал…
P.S. Поддержу так-же точку зрения господина Dee31, что такая избирательность огорчает, а так-же вызывает недоумение…
На мой взгляд изначально вопрос был не в том, как по умолчанию, а как можно сделать договором или другими способами.
В США можно распространить трудовой договор и на код (интеллектуальную собственность) написанный в нерабочее время. В России трудовой договор не может распространяться на нерабочее время.
> Народ использует систему версионного контроля как резервное хранилище.
А почему версии библиотек не должны отслеживаться системами версионного контроля?
Наверное даже спрошу так, почему версия библиотеки в Вашем понимании — это только строка вида 1.2.3?
Вы никогда не патчили библиотеки, не бекпортировали в них изменения из аптрима без обновления всей библиотеки для сохранения ABI/API? По всем этим причинам для меня версии библиотек это не только цифры, но и весь ее код, который должен как минимум логически храниться или быть доступным в репозитории проекта.
Почему такой вывод. Формулировка «столько мне требуется для оплаты и проживания в месяц», говорит о том, что цель только прожить этот месяц. Из ответа не видно желания копить деньги на какую либо глобальную цель (например, на отпуск или хобби) или хотя бы на создание собственной финансовой подушки безопасности (куда могла бы пойти сумма округления).
Ну раз все сразу, то в случае одновременного исчезновения Intel, Microsoft, GNU FSF и Apple, я думаю мне нужно будет искать другую отрасль (скорее всего земледелие), а не думать о том, что будет с моими проектами.
С библиотеками же все проще. Наглядный пример такого исчезновения я Вам привел (с гитхаба кстати).
> А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
И это тоже есть. Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории. Да, можно довести до одного клика, но в условиях множественных окружений это не имеет смысла на машине разработчика, а на билд-сервере все собирается в один клик на всех окружениях, там это имеет смысл.
> У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
У меня очень ограниченный composer, так как Web-интерфейсы занимают меньшую часть моего времени.
Но даже в случае с composer я предпочитаю не перерабатывать сам и упрощать сервисные задачи. Лишние N Мб зависимостей в репозитории меня при этом не пугают, тем более, что их обновления идут в отдельных коммитах и не замусоривают историю.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
> При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
> Что мешает сложить туда же ваши зависимости?
Удобство использования. Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия.
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере. Прочитайте уже перевод слово репозиторий, чтобы перестать ассоциировать его исключительно с системами управления версиями.
Еще раз повторюсь, что в проект имеет смысл складывать сильно связанные компоненты. Слабо связанные имеет смысл хранить, но не в проекте. Тот факт, что свой проект, который я сейчас подразумеваю собирается более чем в 30 окружениях, то каждое отдельное окружение слабо связано с проектом.
Библиотека же может использоваться только конкретной протестированной версии, так как ABI-совместимость и все такое — это сильно связанная компонента.
> github.com/pathscale?
Там есть исходники компилятора, который они выкладывали?
Оно было здесь: http://www.path64.org/ и https://github.com/path64, но исчезло и сылки с path64.org теперь ведут в никуда (например, github.com/path64/compiler).
Во вторых, мой софт использует конкретную версию конкретной библиотеки, ее имеет смысл положить рядом. Компилируется же он в трех десятках окружений гарантированно и я не знаю в скольки еще линуксах скорее всего. Их не имеет смысла держать совсем рядом, при этом, как я уже писал выше, все компоненты окружений и сборки сборочных виртуальных машин аккуратно сложены в отдельном каталоге на файловом сервере.
Не путайте техническое разбиение инфраструктуры на репозитории, сабмодули и прочее с организационной стороной. С организационной точки зрения в моем репозитории есть и компиляторы.
> Стоит ли хранить содержимое папки vendor в наших репозиториях?
Для меня наш репозиторий — это все то, что находится под моим управлением, включая условные svn.company.com, git.company.com, files.company.com, pkg.company.com и другие варианты. Гитхаб и репозитории вендоров по этому определению не наши.
Да, в дальнейшем было уточнение, что вопрос следует понимать как «прямо в репозитории с проектом».
Если брать этот вопрос, то на него однозначно я ответить не могу, однако, склоняюсь к мысли, что можно и хранить, так как единственный контраргумент по сути — это размер репозитория, но для меня это не критично. А на девелоперскую и сборочную машину все равно весь этот объем тащить надо для сборки.
Почему не храним?
Например, у меня в отдельном репозитории лежат и iso-образы сборочной ОС, и клоны репозитория, и скрипты ее автоустановки и автонастройки, чтобы в любой момент времени нужные виртуальные машины могли быть автоматически пересобраны даже если билд-кластер умрет полностью.
Только вот этот репозиторий не git или svn, а отдельный каталог на файловом сервере.
Да, это занимает дополнительное место, но все это дает мне гарантированную воспроизводимость окружения сборки и всех зависимостей (зависимости проектов я тоже храню у себя), что для меня важно.
Ну и независимость от внешних репозиториев в моменты сборки тоже неплохой бонус, а если сборка всегда проводится на чистых машинах, то для загрузчиков зависимостей нужно либо кэши городить, либо каждый билд тащить из интернета сотни мегабайт библиотек.
Ситуация в которой с появлением новых знаний старые работающие решения признаются либо неправильными(неоптимальными), либо ненадежными является на столько типичной, что мне странно, что она для кого-то может быть неожиданной. Для этого не надо быть медиумом. Достаточно быть инженером.
Спросите любого конструктора любой техники сложнее утюга и они ответят Вам точно так-же. В этой части цитаты нет никакого откровения для инженеров.
Легко видеть правильный путь, когда результат достигнут, но чтобы его достичь придется пройти через ошибки и работу с недостатком информации. Черток это понимал, что в вашей цитате подтверждается фразой «Получил огромный опыт и понял, как сильно мы рисковали», а Вы к сожалению нет…
Вы путаете проблему старта в предметной области и дальнейшее развитие в оной.
Старт отличается тем, что Вы или абстрактный человек имеет только вопросы, но не знает даже примерных направлений куда копать, в связи с этим выучиться самостоятельно можно, но из-за частого и не всегда верного выбора направления в слепую «очень много времени будет потрачено просто зря». Наличие же кого-нибудь, кто будет задавать направление этого поиска ответов сократить время обучения в разы.
В дальнейшем же развитии специалиста в ответ на большинство вызовов он сможет сам задавать себе направления поиска, так как его знания помогут это направление определить. Думаю, не сильно ошибусь, если скажу, что в разработке не так много задач, в которых совершенно непонятно с какой стороны пробовать начинать искать решение.
Правда, огорчает тот факт, что этот сериал пережил смену сценаристов и стройность/обоснованность сюжета была принесена в жертву ради понижения порога вхождения в сериал зрителей с любой серии.
Если про мой комментарий, то совершенно нет.
Краткая суть моего комментария — вред нужно оценивать комплексно, а не брать для сравнения двух технологий в первой фактор, где она безусловно проигрывает, а во второй — где она безусловно выигрывает и на этом основании говорить что вторая лучше.
Если же в общем, то да, полностью согласен. Выбросы в реальных условиях эксплуатации по сути не регламентированы.
> смотришь на шлейф дыма за соседним грузовиком
Так это же очевидно. Грузоперевозки — это большие деньги и лоббирование. Кто пойдет против тех, кто и ответить может?
Что же касается сравнительных характеристик, пусть это останется на Вашей совести…
Это манипулирование фактами и как следствие суммарно получилась ложь практически от первого и до последнего слова.
1) ПДК на выбросы частиц сажи для дизелей был всегда, а для бензиновых появился только в ЕВРО-5. Более того, эта норма для бензиновых двигателей точно такая-же, как и для дизелей.
Кстати, в бензиновых двигателях тоже ставят нейтрализаторы и т.д., которые при неисправности могут усложнять запуск двигателя и которые тоже можно снять, но об этом почему-то молчат.
2) Да, дизель выдает больше оксидов азота, так как в его цилиндрах значительно жарче, но при этом выдает в разы меньше угарного газа, углеводородов, летучей органики и т.д.
К сожалению, ни одной статьи на тему, что из этого В КОМПЛЕКСЕ вреднее для экологии я не видел. Везде выдергивают из контекста один параметр и изучают только его влияние.
В очередной раз прошу сообщество подсказать, есть ли исследования опубликованные в серьезных изданиях о комплексном вреде выхлопа разных типов двигателей. Мне, к сожалению, таких найти не удалось. Может быть я плохо или не там искал?
3) Современный дизель компоновочно не сложнее бензинового с непосредственным впрыском, Больше различий, в том числе в весе, из-за повышенных требований к прочности изделия. Ну и за аккумулятором приходится следить.
Что-же касается обслуживания, то за время гарантии разница в цене выйдет в несколько сотен долларов, которые будут полностью компенсированы снижением операционных расходов (мой пепелац с массой 2-2,5т потребляет от 8 до 11 л/100км, у бензиновых пепелацев этой-же марки расход начинается литров с 12, а заканчивается под 20, при этом требуют они бензин, который в наших краях дороже солярки).
> Уже в 2014 году началась кампания по избавлению Европы от дизельных автомобилей – вероятно, в пользу велосипедов…
А это правда. Только причина скорее всего в очередном лоббировании обновления автопарка. В свое время переход на дизеля этому хорошо поспособствовал…
P.S. Поддержу так-же точку зрения господина Dee31, что такая избирательность огорчает, а так-же вызывает недоумение…
В США можно распространить трудовой договор и на код (интеллектуальную собственность) написанный в нерабочее время. В России трудовой договор не может распространяться на нерабочее время.