А fedora не так уж и плоха. За 2.5 месяца баг пофиксили.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora на 1.5 месяца лучше Ubuntu.

Fedora — отличный дистрибутив.

В Ubuntu этот же самый баг был пофикшен за 4 месяца.

Где ссылка на баг? :)

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

ArchLinux — отличный дистрибутив.

А в этой бочке с порохом вообще баги фиксят? Там же только новые добавляют.

Баги должны фиксить в самих проектах, а не в дистрибутиве.

А дистрибутивы че должны делать? Поставлять багованные продукты?

Fedora — отличный дистрибутив.

Fedora — нормальный дистрибутив

Fedora — отличный дистрибутив.

Дебиан - лучше всех.

Дебиан - лучше всех.

Вообще-то FreeBSD. GNU / Linux Debian идёт после.

Для извра^W любителей есть Debian GNU/kFreeBSD.

Debian GNU/kFreeBSD.

Он протух вроде, а фряха цветёт и благоухает, там FF55 даже!

А дистрибутивы че должны делать? Поставлять багованные продукты?

поставлять как есть. Если баги - то с багами.

единственный кто может править код приложения - разработчик приложения

Выводы делайте сами.

КГ/АМ

Ставил вашу федору по молодости, сырая хоть выжимай.

Слака — отличный дистрибутив.

единственный кто может править код приложения - разработчик приложения

Раскрыт источник дохода спо разработчиков: скиньтесь срочно по стольнику или патч не приму и всем будет плохо. И так с каждым пакетом линукса.

Fedora - дерьмо.

Венда - круть.

У федоры тормознутый dnf.

Вспомнилась паста про грабли и Debian

Gentoo — отличный дистрибутив.

Десятка Вин - бесподобна.

Fedora — отличный дистрибутив.

поставлять как есть. Если баги - то с багами.

Например, выкинуть из репы работающее приложение, ради неработающей версии с большей циферкой в номере версии?

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

Fedora — отличный дистрибутив.

очень малое количество багов - про «неработающую версию») если совсем не работет - можно не обновлять, да.

тут наверное, речь о приложении. в котором 1 из 10 кнопочек перестала работать. Стоит ли на него обновляться. Сложный вопрос.

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

имхо, для каждой конкретной софтины существует некий «общественно приемлемый уровень отваливания». Т.е. при наличии установленного количества критических багов, или хотя бы одном блокирующем - обновления не происходит

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

и другой факт: не бывает так, чтобы дистрибутив работал целиком хорошо. Всегда есть отвалившиеся части. Разные «версии» дистрибутива показывают только то, какие приложения отвалились в этот раз

имхо, поэтому идея «версий» дистрибутива совершенно не имеет смысла. Нужен rolling release, обновляемый например, каждый день. Частые обновления позволяют разработчикам мгновенно получить фидбек и зафайлить тикет, что ускоряет починку проблемы

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

Пропатчить версию фиксом из апстрима?

но ни в коем случае ты не можешь пойти и самостоятельно что-то поправить.

Глупость какая. Берёшь и правишь, собираешь и делаешь пакет. Патч отправляешь в апстрим, где его вполне могут принять.

Частые обновления позволяют разработчикам мгновенно получить фидбек и зафайлить тикет, что ускоряет починку проблемы

ну и как, работает в arch в nomacs batch-resize?

в арче есть свои патчи. лично я очень против этого.

мы в своих проектах на работе такую практику забанили технически: дистрибутив может собираться только из Git-репозиториев подпроектов, автоматически. А попасть в Git-репозиторий фикс может только через центральный репозиторий соответствующего подпроекта (нельзя подключить свой). Только через создание тикета в JIRA, с привязанным к нему бранчом, в котоый помещается pull request. Только с обязательным code review. Способов обойти эту схему у обычных разработчиков не существует.

поставлять как есть. Если баги - то с багами.

Нет. Практика у дистростроителей как-раз такая, чтобы в версию дистрибутива поставить наименее багованные версии пакетов

единственный кто может править код приложения - разработчик приложения

Кэп? Если я внесу патч какому-либо приложению, я стану его разработчиком?

ты станешь его разработчиком только когда получишь статус «я - часть команды» (н-р если продукт делает компания, это подразумевает также трудоустройство в эту компанию. Если энтузиасты - руководитель проекта должен принять тебя в команду). А также commit access к единственному главному репозиторию проекта, из которого собираются официальные дистрибутивы.

Нет. Практика у дистростроителей как-раз такая, чтобы в версию дистрибутива поставить наименее багованные версии пакетов

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

Fedora — отличный дистрибутив.

А в вындовс десять этот баг не исправили.

ты станешь его разработчиком только когда получишь статус «я - часть команды»

Сам придумал, или подсказал кто?