Comments 59
Вроде как можно сделать форк проекта на гитхабе и продолжить его разработку. Триггеры так-то и не нужны. Проблема в том, что сложно найти разработчика, который бы взялся поддерживать проект.
Все ссылки будут на оригинальный проект, гугл будет вести на оригинальный проект, пакет-мэнеджеры будут скачивать оригинальную необновлённую библиотеку. В общем не всё так просто.
Если билд процедура берет тупо последнюю версию без вашего ведома, да еще с неконтролируемого репозитория — у меня для вас очень плохие новости. Если вы так делаете, то я рекомендую перестать это делать — уже были случаи, когда автор тупо решал немножко «пошалить».
А если вы хотите последних обновлений и видите, что проект не обновляется — это звоночек о том, что надо искать альтернативу. Вот тут надо и думать о том, чтобы найти форк/создать форк/перейти на что-то другое.
А если вы хотите последних обновлений и видите, что проект не обновляется — это звоночек о том, что надо искать альтернативу. Вот тут надо и думать о том, чтобы найти форк/создать форк/перейти на что-то другое.
Предположим в проекте 30 подключенных внешних либ, следить за каждой?
Не знаю, что вас удивляет, но описанное artskep вполне обычная практика в нормальных ИТ-компаниях, а не бред параноика.
Э… Смотря чего вы хотите от продукта.
Если при его падении/утечке данных/чего-то-еще-придумайте-сами вы теряете деньги, то да — следите за всеми. Клиенту (а, если дело пойдет серьезнее, то суду) пофигу сколько у вас депендюков — надо выполнять условия контракта и законодательства
Если вы это не можете отслеживать — надо найти кого-то кто это будет отслеживать и нести ответственность (естественно, придется заплатить).
Энтерпрайз любит RedHat не потому, что у них все лучше, чем у других бесплатных дистрибутивов Линукса, а потому, что они могут подписать контракт и взять на себя часть рисков.
Если это студенческий курсовик, то, конечно, пофигу. Но в статье речь не о них.
Если при его падении/утечке данных/чего-то-еще-придумайте-сами вы теряете деньги, то да — следите за всеми. Клиенту (а, если дело пойдет серьезнее, то суду) пофигу сколько у вас депендюков — надо выполнять условия контракта и законодательства
Если вы это не можете отслеживать — надо найти кого-то кто это будет отслеживать и нести ответственность (естественно, придется заплатить).
Энтерпрайз любит RedHat не потому, что у них все лучше, чем у других бесплатных дистрибутивов Линукса, а потому, что они могут подписать контракт и взять на себя часть рисков.
Если это студенческий курсовик, то, конечно, пофигу. Но в статье речь не о них.
Да, следить за каждой. Как минимум за секьюрити-обновлениями.
Конечно не следить. Это же сложно. Тащи всё автоматом в продакшен. У меня же работает!
Конечно да. Каждую библиотеку нужно обновлять отдельно, проверив что в ней изменилось и нет ли там breaking changes. У нас в компании, например, библиотеки обновляются только при наличии тикета, и на это выделяется время, что бы всё аккуратно сделать, ничего не сломать и протестировать affected areas.
Нормальные пакетные менеджеры скачивают пакет не с гитхаба, а из репозитория пакетов…
Да, только у пакета на репозитории пакетов обычно тот же владелец что и у репозитория на гитхабе, так что от описанной проблемы это не избавит.
У меня в Gemfile несколько гемов из приватного репозитория, парочка из гитхаба (конкретный бранч) и один указывает на локальный путь (разработка)
Rubygems нормально со всем справляется
Rubygems нормально со всем справляется
Или наобарот, слишком много, когда количество форков после прекращения поддержки превышает разумные пределы. В принципе преемственность полезная штука, в идеале как описанно выше крупные проекты лучше держать под крылом организаций (GNU/Apache/Mozilla и тд), которые будут способны позаботится о судьбе программы/библиотеки — например официально заявить о проблемах чтобы привлечь внимание, если не найдётся разработчиков.
идеале как описанно выше крупные проекты лучше держать под крылом организаций (GNU
Вы смеетесь?
GNU это лицензия, а не организация. FSF, которая эту лицензию придумала формально не занимается разработкой от слова «совсем».
GNU Linux (как самый, наверное, известный продукт под GNU) имеет херову тучу репозиториев не связанных друг с другом, которые поддерживают разные организации с разными целями и разной историей. И еще больше организаций, которые туда коммитят.
GNU Linux жив не потому, что его поддерживает некоторая мифическая организация, а потому что он всем полезен. Во времена моей юности slackware было круто, а ubuntu еще не родилась. Ну даже если оба эти дистрибутива со своими репозиториями сдохнут — что изменится? Да ничего.
Ну вообще лицензия называется GPL.
А GNU (расшифровывается как «GNU's Not Unix!») — операционная система, построенная с использованием ПО, созданного в рамках GNU Project (такие как GNU/Linux, GNU/Hurd и т.д.).
Но организация называется FSF, тут вы правы.
А GNU (расшифровывается как «GNU's Not Unix!») — операционная система, построенная с использованием ПО, созданного в рамках GNU Project (такие как GNU/Linux, GNU/Hurd и т.д.).
Но организация называется FSF, тут вы правы.
Блин, да, тупо попутал аббревиатуры. Обидно.
Но суть остается той же. GNU — продукт под GPL. Это не организация. Организация, которая формально продукт «основала» это FSF, которая сама по себе цель разработки не ставит (а уж тем более не пытается монополизировать ее, т.к. это противоречит самому духу FSF и созданной ей GPL).
Фу, надеюсь сейчас ничего не перепутал
Но суть остается той же. GNU — продукт под GPL. Это не организация. Организация, которая формально продукт «основала» это FSF, которая сама по себе цель разработки не ставит (а уж тем более не пытается монополизировать ее, т.к. это противоречит самому духу FSF и созданной ей GPL).
Фу, надеюсь сейчас ничего не перепутал
GNU — продукт под GPL.В основном да. Но строго говоря отдельные компоненты операционной системы GNU могут быть под другими лицензиями (например, X Window System — под MIT). Насколько я понимаю, главный критерий, влияющий на то, возможно ли включение компонента в GNU ОС — соотвествование принципам free software с точки зрения FSF.
FSF занимается популяризацией СПО и защитой его разработчиков / пользователей.
Я не понимаю, почему вас так волнует взаимоотношение FSF и GNU. Вы можете являться частью GNU и не являться частью FSF, ровно как и наоборот.
Я не понимаю, почему вас так волнует взаимоотношение FSF и GNU. Вы можете являться частью GNU и не являться частью FSF, ровно как и наоборот.
Я про то, что GNU — не организация, которая следит за тем, чтобы все было хорошо.
Я просто стараюсь аккуратнее прокомментировать комментарий выше: geektimes.ru/post/296131/#comment_10481011 где пытались сказать, что держать «под крылом организации» полезно для opensource. В случае GNU это очевидно не так. Я бы даже сказал, что наоборот — организация отстраняется от разработки ради многообразия (и, по факту, занимается только тем, чтобы демонополизировать разработку).
Это вопрос не взаимоотношений, а идеологий, скорее всего.
Я просто стараюсь аккуратнее прокомментировать комментарий выше: geektimes.ru/post/296131/#comment_10481011 где пытались сказать, что держать «под крылом организации» полезно для opensource. В случае GNU это очевидно не так. Я бы даже сказал, что наоборот — организация отстраняется от разработки ради многообразия (и, по факту, занимается только тем, чтобы демонополизировать разработку).
Это вопрос не взаимоотношений, а идеологий, скорее всего.
В «тусовке» GNU множество профессиональных разработчиков, переводчиков, дизайнеров, юристов и куча других специалистов. Зачем вы все время пытаетесь объединить ее с FSF в одно целое и неделимое? FSF была создана уже позже.
Комментируя оригинальный комментарий, я, по правде сказать, даже не знаю, каким образом можно добиться включения своего проекта в GNU. Но если вам как-то удастся это сделать, то можно точно не беспокоиться о смерти своего проекта.
Комментируя оригинальный комментарий, я, по правде сказать, даже не знаю, каким образом можно добиться включения своего проекта в GNU. Но если вам как-то удастся это сделать, то можно точно не беспокоиться о смерти своего проекта.
В «тусовке» GNU полно серьезных контор, делающих деньги. И они даже друг другу конкуренты.
gnu.org — это не весь GNU. Здесь, наверное, у нас взаимонепонимание. По факту уже найти где GNU а где нет уже почти невозможно — код расползся. Согласно GPL каждый форк по своему GNU. И авторство кода тоже расползлось, так что приватизировать GNU уже физически нереально.
Расползание кода и демонополизация этого всего — результат лицензии GPL. Которая изначально была сделана «вирусной», чтобы никак нельзя было монополизировать хотя бы частичку кода. Поэтому ее энтерпрайз недолюбливает, но частенько вынужден использовать.
FSF — это такое же детище Столлмана, как и GPL (и как результат, GNU). Можно спорить кто появился раньше, но это не принципиально.
gnu.org — это не весь GNU. Здесь, наверное, у нас взаимонепонимание. По факту уже найти где GNU а где нет уже почти невозможно — код расползся. Согласно GPL каждый форк по своему GNU. И авторство кода тоже расползлось, так что приватизировать GNU уже физически нереально.
Расползание кода и демонополизация этого всего — результат лицензии GPL. Которая изначально была сделана «вирусной», чтобы никак нельзя было монополизировать хотя бы частичку кода. Поэтому ее энтерпрайз недолюбливает, но частенько вынужден использовать.
FSF — это такое же детище Столлмана, как и GPL (и как результат, GNU). Можно спорить кто появился раньше, но это не принципиально.
Согласно GPL каждый форк по своему GNU.Уточните, пожалуйста, о каком пункте лицензии идет речь?
И авторство кода тоже расползлось, так что приватизировать GNU уже физически нереально.Большинство авторов отдают свои права в пользу FSF. Но приватизировать код нельзя по другой причине, потому что автор (не важно, FSF, или конкретный человек) в свое время опубликовали его под лицензией GPL. С этих пор программа становится «свободной» (в понимании RMS) и может продолжать жить независимо от хотелок корпораций или той же FSF.
В любом случае, я не понимаю, как из всего этого следует вывод:
где пытались сказать, что держать «под крылом организации» полезно для opensource. В случае GNU это очевидно не так.
Уточните, пожалуйста, о каком пункте лицензии идет речь?
Во-первых, вспомните что означает буква G в GPL
Во-вторых: пункт 2a (я читаю под GPLv2 www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)
You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change
Т.е. если это был GNU проект он как бы им и остается — позволяется только делать изменения в нем (и об этом явно указывать)
Там, конечно, есть секция про то, что можно выдирать куски. Но все-таки большинство форков GNU, очевидно, не такие.
В любом случае, я не понимаю, как из всего этого следует вывод
GNU не организация. FSF не контролирует GNU. Большинство коммиттеров в GNU вообще левые конторы (подчас конкурирующие).
Вывод — GNU не контролируется какой-то организацией, но при этом успешный opensource проект.
Л — логика.
Во-первых, вспомните что означает буква G в GPLБуквы MIT означают Massachusetts Institute of Technology, но это не делает код, опубликованный под лицензией MIT, собственностью института. Также наличие буквы G не делает код, опубликованный под GPL, частью проекта GNU.
Т.е. если это был GNU проект он как бы им и остается — позволяется только делать изменения в нем (и об этом явно указывать)Если я форкну GNU Emacs и назову его Kafemacs, последний не станет автоматически частью проекта GNU.
Л — логика.Логика должна показывать, как из A следует B. Сейчас я не вижу следствия между умозаключениями «держать „под крылом организации“ полезно для opensource. В случае GNU это очевидно не так.» и «GNU не контролируется какой-то организацией, но при этом успешный opensource проект».
Позвольте поинтересоваться, какой опыт работы с проектами в GNU/Mozilla/Apache/etc. у вас имеется? У меня есть знакомый в Mozilla Foundation на fulltime, я сам являюсь одновременно участником одного из проектов GNU и ассоциативным членом FSF. И, конечно, я не утверждаю, что в GNU вашему проекту будет лучше, чем в тех же Apache или Mozilla, но ваше утверждение «это очевидно не так» относительно наречия «полезно» без возможности доказать свою позицию, мягко скажем, вызывает вопросы в вашей компетентности по данному вопросу. И за сем я не вижу смысла продолжать этот спор.
GNU-кун в треде.
GNU — это проект по разработке свободного программного обеспечения, а также одноименная операционная система. В рамках этого проекта в т. ч. разработано несколько свободных лицензий, таких как GPL.
Проекта «GNU Linux», на сколько я знаю, не существует, и никогда не существовало. Однако, есть масса дистрибутивов (вроде тех же Slackware или Ubuntu), которые используют код ОС GNU, а ядро заменяют на Linux. Такие дистрибутивы называются «основанные на GNU/Linux», чтобы отличить их от полностью основанных на Linux систем вроде Android, а также систем, основанных на GNU, но с другим ядром (например, GNU Hurd).
GNU — это проект по разработке свободного программного обеспечения, а также одноименная операционная система. В рамках этого проекта в т. ч. разработано несколько свободных лицензий, таких как GPL.
Проекта «GNU Linux», на сколько я знаю, не существует, и никогда не существовало. Однако, есть масса дистрибутивов (вроде тех же Slackware или Ubuntu), которые используют код ОС GNU, а ядро заменяют на Linux. Такие дистрибутивы называются «основанные на GNU/Linux», чтобы отличить их от полностью основанных на Linux систем вроде Android, а также систем, основанных на GNU, но с другим ядром (например, GNU Hurd).
Смешались вместе люди, кони…
КМК, если разобрать по частям:
1. Если мы говорим о возможности сопровождать код, то это зависит от лицензии. «университетские» лицензии, GPL, Apache2 — вполне позволяют сопровождать код тем, кому это надо (для GPL это вообще одна из основ на которых она построена). Если лицензия позволяет делать форк — кто-то, да сделает форк, если это надо (см. п.2)
2. Если мы говорим о том, что кто-то захочет сопровождать код — тут не opensource ни проприетарщина не даст гарантии. Сколько серьезных продуктов серьезные конторы сняли с поддержки — не перечесть. Сколько контор тупо ушли с рынка забрав с собой хорошие продукты — еще больше. Во всяком случае с opensource есть шанс, что форк возможен и кто-то захочет его поддерживать(хотя бы и контора, которой надо «для себя»), хотя, конечно есть проблема (см. п.3)
3. Контроль за репозиторием. Тут да, есть проблема, что (скажем честно) мало кто читает лицензии, смотрит на обновления и прочая и прочая. Народ доверяет репозиторию (и, как результат) человеку, которые его контролирует. И тогда малоизвестный форк может «не взлететь». Точно так же как сам репозиторий, кстати, может быть подменен/взломан/чего-там еще. Это все проблемы вечные как жизнь…
Но, прочитав еще раз заголовок, я не понимаю чем подобная проблема смерти автора для опенсорс кода отличается от смерти автора чего-нибудь еще (будь это хоть проприетарный код, хоть книга хоть картина)?
Да, со смертью Пискассо, Дали или Шишкина мы потеряли новые картины от них, а репродукции это уже «не то». Но картины никуда не делись, репродукции печатают, новые художники вдохновляются.
КМК, если разобрать по частям:
1. Если мы говорим о возможности сопровождать код, то это зависит от лицензии. «университетские» лицензии, GPL, Apache2 — вполне позволяют сопровождать код тем, кому это надо (для GPL это вообще одна из основ на которых она построена). Если лицензия позволяет делать форк — кто-то, да сделает форк, если это надо (см. п.2)
2. Если мы говорим о том, что кто-то захочет сопровождать код — тут не opensource ни проприетарщина не даст гарантии. Сколько серьезных продуктов серьезные конторы сняли с поддержки — не перечесть. Сколько контор тупо ушли с рынка забрав с собой хорошие продукты — еще больше. Во всяком случае с opensource есть шанс, что форк возможен и кто-то захочет его поддерживать(хотя бы и контора, которой надо «для себя»), хотя, конечно есть проблема (см. п.3)
3. Контроль за репозиторием. Тут да, есть проблема, что (скажем честно) мало кто читает лицензии, смотрит на обновления и прочая и прочая. Народ доверяет репозиторию (и, как результат) человеку, которые его контролирует. И тогда малоизвестный форк может «не взлететь». Точно так же как сам репозиторий, кстати, может быть подменен/взломан/чего-там еще. Это все проблемы вечные как жизнь…
Но, прочитав еще раз заголовок, я не понимаю чем подобная проблема смерти автора для опенсорс кода отличается от смерти автора чего-нибудь еще (будь это хоть проприетарный код, хоть книга хоть картина)?
Да, со смертью Пискассо, Дали или Шишкина мы потеряли новые картины от них, а репродукции это уже «не то». Но картины никуда не делись, репродукции печатают, новые художники вдохновляются.
Ну, в картинах же не ищут уязвимости, и дыра в картине не приведет к общемировому коллапсу вроде heartbleed'a. Проблема как раз в глобализации, здесь — схемы зависимостей ПО с открытым кодом от вот таких «мелочей» и багов в них.
Heartbleed появился, замечу, на популярном продукте. И узнали о нем ровно по этой же причине.
Пока кому-то продукт интересен — его будут поддерживать (хоть кто-то) и мониторить. Я об этом писал в п.2. Хотя единой конторы, которая бы openssl синхронизировала ЕМНИП не существует. Поэтому и пришлось делать «модный сайт», который привлек бы всех, чтобы обновиться можно было бы разом.
Глобальная зависимость — это факт. Будь это опенсорс, проприетарщина или что-то еще. С опенсорсом единственная разница — можно подсмотреть и (возможно) сделать форк и/или поправить.
Больше разницы нет и быть не может.
Пока кому-то продукт интересен — его будут поддерживать (хоть кто-то) и мониторить. Я об этом писал в п.2. Хотя единой конторы, которая бы openssl синхронизировала ЕМНИП не существует. Поэтому и пришлось делать «модный сайт», который привлек бы всех, чтобы обновиться можно было бы разом.
Глобальная зависимость — это факт. Будь это опенсорс, проприетарщина или что-то еще. С опенсорсом единственная разница — можно подсмотреть и (возможно) сделать форк и/или поправить.
Больше разницы нет и быть не может.
рисование новых картин тем же человеком — это такое.
вот умение и приемы рисования, если не было у мастера учеников, — то они умирают вместе с ним.
недавно в теме про падения ракет (не помню правда в которой, их тут развелось уже больше пяти) — выяснилось, что старые профессионалы в атомной промышленности давно уже перестали обновлять документацию и вписывать все подробности. Чтобы их на пенсию не турнули и молодыми спецами не заменили.
А потом фигак — вопрос «а как это железо\процесс поддерживать?» встает в полный рост. (Не говоря уже — о модернизации, хотя бы безопасно модифицировать «по месту» становится трудновыполнимым)
вот умение и приемы рисования, если не было у мастера учеников, — то они умирают вместе с ним.
недавно в теме про падения ракет (не помню правда в которой, их тут развелось уже больше пяти) — выяснилось, что старые профессионалы в атомной промышленности давно уже перестали обновлять документацию и вписывать все подробности. Чтобы их на пенсию не турнули и молодыми спецами не заменили.
А потом фигак — вопрос «а как это железо\процесс поддерживать?» встает в полный рост. (Не говоря уже — о модернизации, хотя бы безопасно модифицировать «по месту» становится трудновыполнимым)
вот умение и приемы рисования, если не было у мастера учеников, — то они умирают вместе с ним
Да, это печально. Техника сфумато (которой была написана Мона Лиза), скорее всего, умерла с Леонардо да Винчи.
Но, стоит заметить, это как-то не остановило развитие живописи. Не говоря уже об изобразительном искусстве вообще.
Не стоит преувеличивать роль личности в истории.
Проблема, как уже написано, связана с тем, что большое количество проектов хостятся в собственных репозиториях, которые нельзя так просто взять и продолжить.
А также есть пакетные менеджеры, в которые проект вам тоже не так то и просто будет загрузить, если вообще возможно.
Как следствие, подхватить проект получается некому. Разве что на его обломках построить проект с новым именем, но это менее эффективно и таких проектов сразу будет по 5-6 штук, вместо одного.
Ну и странно сравнивать программный код с картинами, которые как бы не развиваются.
Заголовок спойлера
Почему все прочитали про картины, но не читают все остальное.
Ок, будет не opensource, а что-то другое. Проблема с пакетными менеджерами будет легче?
И, похоже, я начинаю терять веру в человечество — похоже народ доверяет пакетным менеджерам больше, чем следует. И, более того, не пытается контролировать их поведение в продуктах.
Если так дело пойдет — не надо дожидаться сильного ИИ, чтобы уронить мир. Несмотря на все попытки контролирования процессов разработки «случайный залетевший дятел» сможет таки уничтожить цивилизацию.
Проблема пропритераного софта лежит в другой плоскости. За него вы платите, а значит, у вас есть какие-то гарантии. В случае opensource это не так, и абсолютно никаких гарантий того, что автор внезапно не забьет на пакет и что больше никто не сможет исправлять в нем проблемы у вас нет. И это проблема, которая обсуждается в статье.
Касательно доверия пакетными менеджерам, а в чем проблема? Вы доверяете пакетным репозиториям дистрибутива Linux, который вы используете? Вы доверяете исходному коду ядра, на котором он запущен? Или, если у вас винда, вы доверяете системе, которая может отправить с вашего компа что угодно и куда угодно. В современном IT безумное количество вещей строится чисто на доверии и я не вижу проблемы в конкретном пакетном менеджере. На мой взгляд, зашитые пароли в IoT куда большая проблема.
Проблема пропритераного софта лежит в другой плоскости. За него вы платите, а значит, у вас есть какие-то гарантии.
Это если его делали для вас. А у массового софта (типа ворда) стоит EULA, что вы его используете на свой страх и риск и AS IS.
Во-вторых — разоряется контора, и привет всем гарантиям.
За него вы платите, а значит, у вас есть какие-то гарантии.Можете попытаться через суд вернуть стоимость лицензии. Если какая-то компания и согласится на такие риски, то это обойдется вам в over9000 денег. И это уж точно не про массовый софт.
В случае opensource это не так, и абсолютно никаких гарантий того, что автор внезапно не забьет на пакет и что больше никто не сможет исправлять в нем проблемы у вас нет.
Полная чушь! Подавляющее большинство опенсорса сейчас делается крупными конторами. И за деньги они дают поддержку и гарантии.
Распространенный пример — RedHat, хотя почти на любой приличный opensource продукт найдется контора, которая за скромную сумму будет обеспечивать поддержку.
Вы плохо читали статью, там основная указанная проблема, согласно которой на самом деле все не так радужно и эти продукты строятся на мелких проектах, у которого такой радости нет.
Не берусь комментировать заявление о том, что Red Hat якобы готова взять на себя ваши риски, но они точно участвуют в «мелочах», из которых состоят их продукты. Довольно часто натыкаюсь на их копирайт в исходниках совершенно разных проектов.
Ну, «взять» или «не взять» — тут вопрос тонкий, но обеспечить тех. поддержку по определенным SLA — это факт. Починят или нет — дело отдельное, но бизнес вполне считает подобное уменьшением рисков.
Конечно, они работают с большим количеством GPL лицензированного кода и обязаны публиковать изменения (и те, кто их использует, должны копирайты за собой тоже тащить). Ну, и под другими лицензиями, вроде, тоже много чего пишут.
Учитывая, что ребята много чего делают это вполне прогнозируемо, что их копирайты расползлись по разным проектам. В этом идея опенсорса как есть.
Конечно, они работают с большим количеством GPL лицензированного кода и обязаны публиковать изменения (и те, кто их использует, должны копирайты за собой тоже тащить). Ну, и под другими лицензиями, вроде, тоже много чего пишут.
Учитывая, что ребята много чего делают это вполне прогнозируемо, что их копирайты расползлись по разным проектам. В этом идея опенсорса как есть.
Я хорошо читал статью. Там нет НИ ОДНОГО упоминания того, чтобы какой-то коммерческий продукт пострадал из-за того, что нельзя было сделать форк или с этим были сложности.
Единственный пример известной проблемы, который привели это heartbleed, который к проблеме не имеет никакого отношения, т.к. на тот момент openssl был живым и поддерживаемым (как и сейчас, собственно говоря). Тупо нашли багу. Бывает…
Единственный пример известной проблемы, который привели это heartbleed, который к проблеме не имеет никакого отношения, т.к. на тот момент openssl был живым и поддерживаемым (как и сейчас, собственно говоря). Тупо нашли багу. Бывает…
То, что код отрыт, вообще мало чего говорит. Родственники могут в течении 70 лет подавать в суд за нелегальное использования кода.
Есть ли сервис, показывающий-раскрывающий информацию (пароли), если не заходить и не отсрочить таймер каждый раз?
Можно такое поведение настроить в gmail. Если не заходить N времени, он пошлет письмо с инструкциями на случай смерти владельца по указанному адресу. Получателем вполне может быть список рассылки.
Например,"google на всякий случай" (гуглить надо вместе со словом google, т.к. я говорю про их продукт). Прямо в письме доверенному человеку пропишите логины, пароли (лучше только пароли, а логины сообщите прямо сейчас другим способом) и другую информацию.
Если кто-то подскажет свободный аналог, который можно запустить на своём хосте, настрою его тоже.
В связи с неизбежностью смерти автора и по мере нарастания связанных с этим проблем, я думаю, что сообщество открытого ПО дорастет до создания типовых завещаний по аналогии с лицензиями. Неудивительно, что код будет жить дольше, чем его создатели.
Какая-то надуманная проблема. При просмотре репозитория на GitHub сразу видно как давно в него вносились правки. Если очень давно — можно посмотреть форки этого репозитория и найти более активный. Если более активного нет — ну, поздравляю, проект умер.
Триггер мертвеца — плохая идея.
Поясню: допустим можно определить период отсутствия логина, который надо считать триггером (как установить этот предел — это еще отдельный вопрос). Но что происходит после срабатывания триггера?
В теории: находится хороший, добропорядочный программист, который берет такой проект под свой контроль.
На практике: обязательно появится хоть один хороший, недобропорядочный программист который внедрит в код проекта какую-нибудь сложно выявляему бяку (бекдор, майнерб да что угодно — выбор сейчас хороший). И да — такой «выкрутас» довольно скоро обнаружат (на то он и опенсорс), но получится что:
1. оригинальный репозиторий — в руках злоумышленника (и с этим нужно что-то делать).
2. зависимые от этого проекта проекты вынуждены будут откатывать обновления и переходить на форк созданный хорошего, добропорядочного программиста (если он найдется)
3. А весь тот вред от внедренного недобропорядочный кода, который он нанесет от момента внедрения до реализации корректирующих мероприятий уже будет не откатить.
В итоге имеем репутационные издержки и реальные потери реальных клиентов.
Можно возразить, что вариант внедрения «недобропорядочного кода» возможен и при живом авторе. Однако репы на том же гитхабе становятся популярными и активно используемыми в других проектах не внезапно, а по мере нарастания «положительной» истории. И вероятность того, что человек много лет делал качественный продукт, а потом вдруг начал внедрять зловред — гораздо ниже чем шанс получить такой зловред после перехода собственности репы по триггеру мертвеца.
Поясню: допустим можно определить период отсутствия логина, который надо считать триггером (как установить этот предел — это еще отдельный вопрос). Но что происходит после срабатывания триггера?
В теории: находится хороший, добропорядочный программист, который берет такой проект под свой контроль.
На практике: обязательно появится хоть один хороший, недобропорядочный программист который внедрит в код проекта какую-нибудь сложно выявляему бяку (бекдор, майнерб да что угодно — выбор сейчас хороший). И да — такой «выкрутас» довольно скоро обнаружат (на то он и опенсорс), но получится что:
1. оригинальный репозиторий — в руках злоумышленника (и с этим нужно что-то делать).
2. зависимые от этого проекта проекты вынуждены будут откатывать обновления и переходить на форк созданный хорошего, добропорядочного программиста (если он найдется)
3. А весь тот вред от внедренного недобропорядочный кода, который он нанесет от момента внедрения до реализации корректирующих мероприятий уже будет не откатить.
В итоге имеем репутационные издержки и реальные потери реальных клиентов.
Можно возразить, что вариант внедрения «недобропорядочного кода» возможен и при живом авторе. Однако репы на том же гитхабе становятся популярными и активно используемыми в других проектах не внезапно, а по мере нарастания «положительной» истории. И вероятность того, что человек много лет делал качественный продукт, а потом вдруг начал внедрять зловред — гораздо ниже чем шанс получить такой зловред после перехода собственности репы по триггеру мертвеца.
Но GitHub не хотел давать Сёрсу управление страницей, поскольку Вайрих не передал ему таких прав перед смертью.
А с чего им хотеть?
Также ему пришлось уговорить операторов Ruby Gems, системы управления пакетами, распространяющей код, использовать его версию Rspec-Given вместо версии Вайнриха, чтобы у всех пользователей был доступ к изменениям, проделанным Сёрлсом.
И они согласились? Очень плохо, если так.
Изначально пользователи "подписывались" на rspec, который пишет и поддерживает конкретный человек. То что их переключили на другую версию без их ведома — это очень плохо.
Я считаю, что такие вещи не должны происходить неявно. Мне бы не хотелось, чтобы после моей смерти кто-то получил доступ к моим публичным репозиториям и мог бы публиковать там изменения как будто бы от моего имени.
Продумать заранее, кому и как передать такие права — это хорошая идея. Но передавать их уже после смерти человека, если он при жизни не дал на это разрешение — очень плохая идея.
Изначально пользователи «подписывались» на rspec, который пишет и поддерживает конкретный человек. То что их переключили на другую версию без их ведома — это очень плохо.Если пользователь указывал в Gemfile конкретную версию пакета, написанную конкретным человеком (например rspec-given 3.4.0), то никто его на другую версию, написанную другим человеком, не переключит. И даже на другую версию, написанную тем же самым человеком не переключит. Если же конкретную версию не указывал — ну так это и подразумевает, что его может со временем переключить на другую версию, и кем она будет написана — в общем случае не известно (хотя бы потому, что предыдущий автор может передать управление пакетом кому угодно).
хотя бы потому, что предыдущий автор может передать управление пакетом кому угодно
Есть разница между случаем, когда предыдущий автор передаёт управление кому-то; и случаем, когда управление передают без ведома предыдущего автора (потому что он мёртв).
Разница-то, конечно есть, но в обоих случаях вас без вашего ведома «переключат» на другую версию, написанную другим человеком.
Обезопасить себя от такого, как я писал выше, очень просто — указать конкретную версию.
Обезопасить себя от такого, как я писал выше, очень просто — указать конкретную версию.
Это понятно, но тем не менее. Забирать у автора проект только потому, что автор умер и не может возразить — очень плохая практика, ИМХО.
указать конкретную версию
Я не знаю, как там в этих ваших рубях принято, но у нас в пейтоне все делают pip freeze > requirements.txt, и все зависимости фризятся с указанием точной версии, так что ситуация с неявным обновлением невозможна.
Sign up to leave a comment.
Судьба проекта с открытым кодом после смерти программиста