История изменений

Python Image Library и ее разработчики совсем все О_О? (комментарий)

Естественно. Если они не слезли с неподдерживаемого языка/фреймворка то они сами по себе неподдерживаемые, а значит уязвимые, никем не тестируемые, но требующие при этом сил на поддержку, и они подведут в самый ответственный момент.

неподдерживаемые, а значит уязвимые

Из первого не обязательно следует второе.

Во-первых, риски бывают разные — от пренебрежимо малых в случае оффлайнового софта в песочнице и работе с проверенными данными, до высоких — сетевой сервис, обработка данных, переданных третьей стороной.

Во-вторых, это не значит, что поддерживаемый софт защищен и не имеет 0-day. Превентивная защита нужна в любом случае: ограничение прав, запуск в песочницах.

никем не тестируемые

К сожалению, такое случается и с поддерживаемым ПО. Код пишут быстрее, чем тесты. QA — роскошь для многих свободных проектов. Энтузиасты тестируют в процессе использования.

но требующие при этом сил на поддержку

Разве не в следствии того самого принудительного ломания совместимости требуются дополнительные силы на поддержку? Почему законченный готовый продукт не может запускаться так долго, как этого потребуется, без изменений в кодовой базе? Ладно, не бесконечно долго, но хотя бы лет 20.

и они подведут в самый ответственный момент

Этой гарантии обычно нет нигде, и не может быть, о чём явно указывают в лицензиях. Такое случается и с поддерживаемым софтом при неудачном апдейте, вплоть до рекурсивного удаления данных пользователя.

Вы будете такой весь в себе просветлённый работает-не-трогай гуру, а потом рраз - и проект перестаёт работать от слова совсем. Гуру, за невозможностью ничего сделать успешно выпинывается, и, что характерно, просто идёт вредить в другую контору, а бизнес потом ищет ему замену за любые деньги, и не может найти, пока сам не развалится.

Я бы не стал сейчас обсуждать бизнес, там другое управление рисками, и отличается от использования ПО обычными пользователями или энтузиастами.

Понимаешь какая штука, весь софт как был написал потому что кому-то нужен, так и поддерживается потому что кому-то нужен.

Чтобы объяснить, почему это не совсем так, придется усложнить объяснение. Есть множество тех, кому софт нужен, множество тех, кто умеет его написать/поддерживать, и множество тех, кто решительно настроен это сделать. В пересечении этих множеств находятся авторы софта и ментейнеры.

Если он не написан, значит никому ещё не понадобился настолько чтобы его написать, аналогично если не поддерживается значит никто им не пользуется чтобы был смысл его поддерживать.

И здесь тоже пригодится вышеупомянутый пример с множествами. Когда случается, что авторы или ментейнеры теряют возможность сопровождать софт (причин множество: семья, основная работа, новые увлечения, bus factor, выгорание, здоровье), то это не значит, что пропадают пользователи или инженеры, которые хотели бы поддерживать, но пока не имеют возможности потратить n человекочасов.

Если рассуждать, что есть только два варианта: чёрное или белое, нужен или не нужен, то всё просто. На практике есть градации. Например, ПО полезное и пользователям упрощает некоторые задачи или добавляет некоторого комфорта. Но они не готовы организоваться и собрать несколько сотен или тысяч долларов, чтобы нанять фрилансера или того же автора, сделать форк и образовать коммьюнити вокруг него. Это отличается от варианта, когда рабочий доступный софт не используется, потому что никому не нужен. По-настоящему никому не нужен.

Если он никому не нужен, а тебе вдруг почему-то нужен, значит ты либо что-то делаешь не так (не знаешь и не хочешь знать об альтернативах, например), либо хочешь чтобы что-то нужное только тебе поддерживали другие люди. В обоих случаях ты идёшь лесом со своим нытьём и, заметь, сообщество от этого ничего не теряет.

Если пользователь выполняет свои привычные задачи привычным инструментом, но очередное обновление его ломает — это проблема системы, а не пользователя. Проблема даже не в том, чтобы поддерживали, а в том, чтобы не ломали userspace.

Во-первых, не надо путать труд и результат труда. Труд нельзя выкинуть, он уже произведён, и привёл как к появлению непосредственных результатов, так и лёг в основу последующего развития.

Согласен.

А результаты - это временное явление, естественно устревающее сразу после своего появления.

Тоже согласен. Вопрос во временных рамках: в одном окружении (ОС, язык, фреймворк, библиотеки) результат труда может быть сломан через пару лет, в другом окружении благодаря стабильному API, ABI и прослойкам совместимости результатом труда можно пользоваться и спустя лет 20.

Всё у чего не появилось конкурентов или в чём не исчезла надобность, поддерживается и 10, и 20 и 50 лет. А остальное само радо отправиться на помойку, потому что это освобождает силы для более актуальных проектов.

Если у проекта пропали активные разработчики и ментейнеры, то это не значит, что обязательно пропали пользователи. Просто в текущих реалиях им приходится мигрировать на новые проекты, потому что им не оставляют выбора. Если поспрашивать пользователей, какой процент из них будет позитивно воспринимать принудительную смену используемых и привычных программ?

Смотри-смотри, хоть в вверх ногами сношайся, только бы стоимость этих сношений оставалась меньше стоимости актуализации кодовой базы или миграции на актуальное решение. Факт в том что почти все старьёвщики заблуждаются по поводу отношения этих стоимостей.

Зависит от того, как используется решение. Я не обсуждаю сейчас бизнес, а также я против использования старого неподдерживаемого софта/библиотек на публичных серверах. Но если это оффлайновое ПО, которое просто выполняет свои задачи для пользователя, то что мешает ему выполнять их дальше, кроме как принудительное ломание userspace?

Python Image Library и ее разработчики совсем все О_О? (комментарий)

Естественно. Если они не слезли с неподдерживаемого языка/фреймворка то они сами по себе неподдерживаемые, а значит уязвимые, никем не тестируемые, но требующие при этом сил на поддержку, и они подведут в самый ответственный момент.

неподдерживаемые, а значит уязвимые

Из первого не обязательно следует второе.

Во-первых, риски бывают разные — от пренебрежимо малых в случае оффлайнового софта в песочнице и работе с проверенными данными, до высоких — сетевой сервис, обработка данных, переданных третьей стороной.

Во-вторых, это не значит, что поддерживаемый софт защищен и не имеет 0-day. Превентивная защита нужна в любом случае: ограничение прав, запуск в песочницах.

никем не тестируемые

К сожалению, такое случается и с поддерживаемым ПО. Код пишут быстрее, чем тесты. QA — роскошь для многих свободных проектов. Энтузиасты тестируют в процессе использования.

но требующие при этом сил на поддержку

Не следствие ли это того самого принудительного ломания совместимости? Почему законченный готовый продукт не может запускаться так долго, как этого потребуется, без изменений в кодовой базе? Ладно, не бесконечно долго, но хотя бы лет 20.

и они подведут в самый ответственный момент

Этой гарантии обычно нет нигде, и не может быть, о чём явно указывают в лицензиях. Такое случается и с поддерживаемым софтом при неудачном апдейте, вплоть до рекурсивного удаления данных пользователя.

Вы будете такой весь в себе просветлённый работает-не-трогай гуру, а потом рраз - и проект перестаёт работать от слова совсем. Гуру, за невозможностью ничего сделать успешно выпинывается, и, что характерно, просто идёт вредить в другую контору, а бизнес потом ищет ему замену за любые деньги, и не может найти, пока сам не развалится.

Я бы не стал сейчас обсуждать бизнес, там другое управление рисками, и отличается от использования ПО обычными пользователями или энтузиастами.

Понимаешь какая штука, весь софт как был написал потому что кому-то нужен, так и поддерживается потому что кому-то нужен.

Чтобы объяснить, почему это не совсем так, придется усложнить объяснение. Есть множество тех, кому софт нужен, множество тех, кто умеет его написать/поддерживать, и множество тех, кто решительно настроен это сделать. В пересечении этих множеств находятся авторы софта и ментейнеры.

Если он не написан, значит никому ещё не понадобился настолько чтобы его написать, аналогично если не поддерживается значит никто им не пользуется чтобы был смысл его поддерживать.

И здесь тоже пригодится вышеупомянутый пример с множествами. Когда случается, что авторы или ментейнеры теряют возможность сопровождать софт (причин множество: семья, основная работа, новые увлечения, bus factor, выгорание, здоровье), то это не значит, что пропадают пользователи или инженеры, которые хотели бы поддерживать, но пока не имеют возможности потратить n человекочасов.

Если рассуждать, что есть только два варианта: чёрное или белое, нужен или не нужен, то всё просто. На практике есть градации. Например, ПО полезное и пользователям упрощает некоторые задачи или добавляет некоторого комфорта. Но они не готовы организоваться и собрать несколько сотен или тысяч долларов, чтобы нанять фрилансера или того же автора, сделать форк и образовать коммьюнити вокруг него. Это отличается от варианта, когда рабочий доступный софт не используется, потому что никому не нужен. По-настоящему никому не нужен.

Если он никому не нужен, а тебе вдруг почему-то нужен, значит ты либо что-то делаешь не так (не знаешь и не хочешь знать об альтернативах, например), либо хочешь чтобы что-то нужное только тебе поддерживали другие люди. В обоих случаях ты идёшь лесом со своим нытьём и, заметь, сообщество от этого ничего не теряет.

Если пользователь выполняет свои привычные задачи привычным инструментом, но очередное обновление его ломает — это проблема системы, а не пользователя. Проблема даже не в том, чтобы поддерживали, а в том, чтобы не ломали userspace.

Во-первых, не надо путать труд и результат труда. Труд нельзя выкинуть, он уже произведён, и привёл как к появлению непосредственных результатов, так и лёг в основу последующего развития.

Согласен.

А результаты - это временное явление, естественно устревающее сразу после своего появления.

Тоже согласен. Вопрос во временных рамках: в одном окружении (ОС, язык, фреймворк, библиотеки) результат труда может быть сломан через пару лет, в другом окружении благодаря стабильному API, ABI и прослойкам совместимости результатом труда можно пользоваться и спустя лет 20.

Всё у чего не появилось конкурентов или в чём не исчезла надобность, поддерживается и 10, и 20 и 50 лет. А остальное само радо отправиться на помойку, потому что это освобождает силы для более актуальных проектов.

Если у проекта пропали активные разработчики и ментейнеры, то это не значит, что обязательно пропали пользователи. Просто в текущих реалиях им приходится мигрировать на новые проекты, потому что им не оставляют выбора. Если поспрашивать пользователей, какой процент из них будет позитивно воспринимать принудительную смену используемых и привычных программ?

Смотри-смотри, хоть в вверх ногами сношайся, только бы стоимость этих сношений оставалась меньше стоимости актуализации кодовой базы или миграции на актуальное решение. Факт в том что почти все старьёвщики заблуждаются по поводу отношения этих стоимостей.

Зависит от того, как используется решение. Я не обсуждаю сейчас бизнес, а также я против использования старого неподдерживаемого софта/библиотек на публичных серверах. Но если это оффлайновое ПО, которое просто выполняет свои задачи для пользователя, то что мешает ему выполнять их дальше, кроме как принудительное ломание userspace?

Python Image Library и ее разработчики совсем все О_О? (комментарий)

Естественно. Если они не слезли с неподдерживаемого языка/фреймворка то они сами по себе неподдерживаемые, а значит уязвимые, никем не тестируемые, но требующие при этом сил на поддержку, и они подведут в самый ответственный момент.

неподдерживаемые, а значит уязвимые

Из первого не обязательно следует второе.

Во-первых, риски бывают разные — от пренебрежимо малых в случае оффлайнового софта в песочнице и работе с проверенными данными, до высоких — сетевой сервис, обработка данных, переданных третьей стороной.

Во-вторых, это не значит, что поддерживаемый софт защищен и не имеет 0-day. Превентивная защита нужна в любом случае: ограничение прав, запуск в песочницах.

никем не тестируемые

К сожалению, эта проблема есть и с поддерживаемым ПО. Код пишут быстрее, чем тесты. QA — роскошь для многих свободных проектов. Энтузиасты тестируют в процессе использования.

но требующие при этом сил на поддержку

Не следствие ли это того самого принудительного ломания совместимости? Почему законченный готовый продукт не может запускаться так долго, как этого потребуется, без изменений в кодовой базе? Ладно, не бесконечно долго, но хотя бы лет 20.

и они подведут в самый ответственный момент

Этой гарантии обычно нет нигде, и не может быть, о чём явно указывают в лицензиях. Такое случается и с поддерживаемым софтом при неудачном апдейте, вплоть до рекурсивного удаления данных пользователя.

Вы будете такой весь в себе просветлённый работает-не-трогай гуру, а потом рраз - и проект перестаёт работать от слова совсем. Гуру, за невозможностью ничего сделать успешно выпинывается, и, что характерно, просто идёт вредить в другую контору, а бизнес потом ищет ему замену за любые деньги, и не может найти, пока сам не развалится.

Я бы не стал сейчас обсуждать бизнес, там другое управление рисками, и отличается от использования ПО обычными пользователями или энтузиастами.

Понимаешь какая штука, весь софт как был написал потому что кому-то нужен, так и поддерживается потому что кому-то нужен.

Чтобы объяснить, почему это не совсем так, придется усложнить объяснение. Есть множество тех, кому софт нужен, множество тех, кто умеет его написать/поддерживать, и множество тех, кто решительно настроен это сделать. В пересечении этих множеств находятся авторы софта и ментейнеры.

Если он не написан, значит никому ещё не понадобился настолько чтобы его написать, аналогично если не поддерживается значит никто им не пользуется чтобы был смысл его поддерживать.

И здесь тоже пригодится вышеупомянутый пример с множествами. Когда случается, что авторы или ментейнеры теряют возможность сопровождать софт (причин множество: семья, основная работа, новые увлечения, bus factor, выгорание, здоровье), то это не значит, что пропадают пользователи или инженеры, которые хотели бы поддерживать, но пока не имеют возможности потратить n человекочасов.

Если рассуждать, что есть только два варианта: чёрное или белое, нужен или не нужен, то всё просто. На практике есть градации. Например, ПО полезное и пользователям упрощает некоторые задачи или добавляет некоторого комфорта. Но они не готовы организоваться и собрать несколько сотен или тысяч долларов, чтобы нанять фрилансера или того же автора, сделать форк и образовать коммьюнити вокруг него. Это отличается от варианта, когда рабочий доступный софт не используется, потому что никому не нужен. По-настоящему никому не нужен.

Если он никому не нужен, а тебе вдруг почему-то нужен, значит ты либо что-то делаешь не так (не знаешь и не хочешь знать об альтернативах, например), либо хочешь чтобы что-то нужное только тебе поддерживали другие люди. В обоих случаях ты идёшь лесом со своим нытьём и, заметь, сообщество от этого ничего не теряет.

Если пользователь выполняет свои привычные задачи привычным инструментом, но очередное обновление его ломает — это проблема системы, а не пользователя. Проблема даже не в том, чтобы поддерживали, а в том, чтобы не ломали userspace.

Во-первых, не надо путать труд и результат труда. Труд нельзя выкинуть, он уже произведён, и привёл как к появлению непосредственных результатов, так и лёг в основу последующего развития.

Согласен.

А результаты - это временное явление, естественно устревающее сразу после своего появления.

Тоже согласен. Вопрос во временных рамках: в одном окружении (ОС, язык, фреймворк, библиотеки) результат труда может быть сломан через пару лет, в другом окружении благодаря стабильному API, ABI и прослойкам совместимости результатом труда можно пользоваться и спустя лет 20.

Всё у чего не появилось конкурентов или в чём не исчезла надобность, поддерживается и 10, и 20 и 50 лет. А остальное само радо отправиться на помойку, потому что это освобождает силы для более актуальных проектов.

Если у проекта пропали активные разработчики и ментейнеры, то это не значит, что обязательно пропали пользователи. Просто в текущих реалиях им приходится мигрировать на новые проекты, потому что им не оставляют выбора. Если поспрашивать пользователей, какой процент из них будет позитивно воспринимать принудительную смену используемых и привычных программ?

Смотри-смотри, хоть в вверх ногами сношайся, только бы стоимость этих сношений оставалась меньше стоимости актуализации кодовой базы или миграции на актуальное решение. Факт в том что почти все старьёвщики заблуждаются по поводу отношения этих стоимостей.

Зависит от того, как используется решение. Я не обсуждаю сейчас бизнес, а также я против использования старого неподдерживаемого софта/библиотек на публичных серверах. Но если это оффлайновое ПО, которое просто выполняет свои задачи для пользователя, то что мешает ему выполнять их дальше, кроме как принудительное ломание userspace?

Python Image Library и ее разработчики совсем все О_О? (комментарий)

Естественно. Если они не слезли с неподдерживаемого языка/фреймворка то они сами по себе неподдерживаемые, а значит уязвимые, никем не тестируемые, но требующие при этом сил на поддержку, и они подведут в самый ответственный момент.

неподдерживаемые, а значит уязвимые

Bз первого не обязательно следует второе.

Во-первых, риски бывают разные — от пренебрежимо малых в случае оффлайнового софта в песочнице и работе с проверенными данными, до высоких — сетевой сервис, обработка данных, переданных третьей стороной.

Во-вторых, это не значит, что поддерживаемый софт защищен и не имеет 0-day. Превентивная защита нужна в любом случае: ограничение прав, запуск в песочницах.

никем не тестируемые

К сожалению, это проблема есть и с поддерживаемым ПО. Код пишут быстрее, чем тесты. QA — роскошь для многих свободных проектов. Энтузиасты тестируют в процессе использования.

но требующие при этом сил на поддержку

Не следствие ли это того самого принудительного ломания совместимости? Почему законченный готовый продукт не может запускаться так долго, как этого потребуется, без изменений в кодовой базе? Ладно, не бесконечно долго, но хотя бы лет 20.

и они подведут в самый ответственный момент

Этой гарантии обычно нет нигде, и не может быть, о чём явно указывают в лицензиях. Такое случается и с поддерживаемым софтом при неудачном апдейте, вплоть до рекурсивного удаления данных пользователя.

Вы будете такой весь в себе просветлённый работает-не-трогай гуру, а потом рраз - и проект перестаёт работать от слова совсем. Гуру, за невозможностью ничего сделать успешно выпинывается, и, что характерно, просто идёт вредить в другую контору, а бизнес потом ищет ему замену за любые деньги, и не может найти, пока сам не развалится.

Я бы не стал сейчас обсуждать бизнес, там другое управление рисками, и отличается от использования ПО обычными пользователями или энтузиастами.

Понимаешь какая штука, весь софт как был написал потому что кому-то нужен, так и поддерживается потому что кому-то нужен.

Чтобы объяснить, почему это не совсем так, придется усложнить объяснение. Есть множество тех, кому софт нужен, множество тех, кто умеет его написать/поддерживать, и множество тех, кто решительно настроен это сделать. В пересечении этих множеств находятся авторы софта и ментейнеры.

Если он не написан, значит никому ещё не понадобился настолько чтобы его написать, аналогично если не поддерживается значит никто им не пользуется чтобы был смысл его поддерживать.

И здесь тоже пригодится вышеупомянутый пример с множествами. Когда случается, что авторы или ментейнеры теряют возможность сопровождать софт (причин множество: семья, основная работа, новые увлечения, bus factor, выгорание, здоровье), то это не значит, что пропадают пользователи или инженеры, которые хотели бы поддерживать, но пока не имеют возможности потратить n человекочасов.

Если рассуждать, что есть только два варианта: чёрное или белое, нужен или не нужен, то всё просто. На практике есть градации. Например, ПО полезное и пользователям упрощает некоторые задачи или добавляет некоторого комфорта. Но они не готовы организоваться и собрать несколько сотен или тысяч долларов, чтобы нанять фрилансера или того же автора, сделать форк и образовать коммьюнити вокруг него. Это отличается от варианта, когда рабочий доступный софт не используется, потому что никому не нужен. По-настоящему никому не нужен.

Если он никому не нужен, а тебе вдруг почему-то нужен, значит ты либо что-то делаешь не так (не знаешь и не хочешь знать об альтернативах, например), либо хочешь чтобы что-то нужное только тебе поддерживали другие люди. В обоих случаях ты идёшь лесом со своим нытьём и, заметь, сообщество от этого ничего не теряет.

Если пользователь выполняет свои привычные задачи привычным инструментом, но очередное обновление его ломает — это проблема системы, а не пользователя. Проблема даже не в том, чтобы поддерживали, а в том, чтобы не ломали userspace.

Во-первых, не надо путать труд и результат труда. Труд нельзя выкинуть, он уже произведён, и привёл как к появлению непосредственных результатов, так и лёг в основу последующего развития.

Согласен.

А результаты - это временное явление, естественно устревающее сразу после своего появления.

Тоже согласен. Вопрос во временных рамках: в одном окружении (ОС, язык, фреймворк, библиотеки) результат труда может быть сломан через пару лет, в другом окружении благодаря стабильному API, ABI и прослойкам совместимости результатом труда можно пользоваться и спустя лет 20.

Всё у чего не появилось конкурентов или в чём не исчезла надобность, поддерживается и 10, и 20 и 50 лет. А остальное само радо отправиться на помойку, потому что это освобождает силы для более актуальных проектов.

Если у проекта пропали активные разработчики и ментейнеры, то это не значит, что обязательно пропали пользователи. Просто в текущих реалиях им приходится мигрировать на новые проекты, потому что им не оставляют выбора. Если поспрашивать пользователей, какой процент из них будет позитивно воспринимать принудительную смену используемых и привычных программ?

Смотри-смотри, хоть в вверх ногами сношайся, только бы стоимость этих сношений оставалась меньше стоимости актуализации кодовой базы или миграции на актуальное решение. Факт в том что почти все старьёвщики заблуждаются по поводу отношения этих стоимостей.

Зависит от того, как используется решение. Я не обсуждаю сейчас бизнес, а также я против использования старого неподдерживаемого софта/библиотек на публичных серверах. Но если это оффлайновое ПО, которое просто выполняет свои задачи для пользователя, то что мешает ему выполнять их дальше, кроме как принудительное ломание userspace?