Стандартный комментарий про арч.

Это проблема их обоих.

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

И кстати, с ведром такое происходит постоянно, просто в этом раз не повезло именно тебе.

Разработчики дистрибутива а) не имеют к этому никакого отношения б) не могут с этим ничего поделать.

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

Думаешь, если бы я мог с этим что-то поделать, я бы бросился покупать десять новых вайфай-свистков на собственное бабло?

Тут уже кто-то предлагал взять новую сетевую карточку у соседа/коллеги. Но это ламерский путь. Так можно делать лишь от безисходности и от безответственности дистро/апстримо-строителей.

Угадай.

Надо было бэкапы делать перед обновлением, бгг.

да я уже догадался, лишь бы бзднуть в лужу

зы. over 9000 бесполезных комментов в толксах и 1 звезда ззы. комментарий прописан, в игнор добавлен

Есть такое понятие, «зона ответственности». Зона ответственности автора vim - редактор vim. Зона ответственности автора pacman из arch - его pacman. Автор pacman'а не будет фиксать vim, это не его задача. Если тебе нужно разобраться в вопросе а) найди того человека, чьей зоной ответственности является производство твоего драйвера б) найти коммит, который добавил баг, и человека, который является его автором в) напиши ответственному за драйвер с копией на автора коммита, (с копией на Торвальдса), что за фигня творится. Ты можешь оставить на арчефоруме сколько угодно багрепортов, но люди не будут фиксить то, что не входит в их зону ответственности. Иногда баги апстрима все же исправляются, в случае абсолютной безысходности типа «новое ядро не грузится ни у кого» или «у всех падает плазма», но в общем случае соваться не в свои дела - плохо.

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

После закрытия критических багов.

И кстати, с ведром такое происходит постоянно, просто в этом раз не повезло именно тебе.

Тогда для чего существует тестовый репозиторий? Не для того ли, чтобы подобные эпикфейлы случались именно там?

могут сами сообщить в апстрим о проблеме.

сообщить - могут, и наверняка уже сообщили. править - нет, это не их дело.

Есть такое понятие, «зона ответственности».

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

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

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

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

править - нет, это не их дело.

У большинства дистрибутивов пропатченые ядра. В том числе и у Arch-а.

Use Debian же. И вообще - с чего взято, что причина в апдейте ядра? Что там ещё с ним обновлялось?

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

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

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

И к ним и к дистростроителя. Тестированием должны заниматься оба.

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

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

Следовательно ты не прав и не все критические баги были закрыты.

Подразумевалось, выявленные на тот момент.

Подразумевалось, выявленные на тот момент.

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

!

Я предполагал хотя бы какое-то подобие нормального тестирования.

Я же вроде давал ссылку на арчевский багтрекер. Вот еще раз. Они знали про баг, когда выпускали ядро в [core]... это часть философии ArchLinux: если у апстрима есть проблемы, пусть апстрим их и решает. Баг в приложении != баг в пакете, спорно, но так есть. Патч, откатывающий последнии комиты и решающий эту проблему уже был на http://bugzilla.kernel.org/... можно было выпустить ядро в котором ваша сетевуха работает, но в ArchLinux так не принято...

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

Дальше «дистростроители».

Мантейнеры пакетов - отладка _интеграции_ конкретных пакетов, за которые они отвечают. Иногда - залатывание супер-критических багов собственными патчами. (Прога делает rm -rf /* - это надо патчить.)

Разработчики внутренних проектов (https://projects.archlinux.org) - разработка и поддержка внутренних проектов (полный цикл, включая тестирование). Они могут накладывать патчи на пакеты в случае их некорректной интеграции системными тулзами (прога при сборке хочет писать конфиги в /usr/bin - это надо пофиксать, ядро не грузится - это надо пофиксать) по результатам обсуждения в рассылке с непосредстенными мантейнерами пакета и другими связанными персонажами.

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

Интеграторы - непосредственные пользователи, занимающиеся установкой и поддержкой арча на компьютерах других пользователей, ответами/поддержкой на форумах или обладатели большого количество компьютеров на арче (корпоративная сетка на 100 компьютеров пойдет). Они могут в рекомендательном порядке давать советы и другую обратную связь и обязательно предлагать решения.

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

Legacy код и код, оставшийся совсем без мантейнеров отправляется в AUR. Наиболее востребованные и поддерживаемые пакеты из AUR'а отправляются в основные репозитории.

Если не разграничивать зоны ответственности, то получится Убунта, в которой куча хрен знает откуда взявшихся и как работающих патчей с непонятными авторами, на просьбу убрать которые в багтрекере отвечают «все работает, почему - не знаем, но не трожьте!». Именно поэтому я не асилил Убунту - она слишком сложная - невозможно разобраться, что откуда взялось, как это починить, у кого спросить помощи, итп.

Торвальдс гонит паровоз

скорее всего, Торвальдс там вообще не при чем. Торвальдс мерджит коммиты-фичи и осуществляет общее руководство. Драйвер пишет автор, который за него отвечает. Автор прислал патч, сказал что он stable, Линус глянул что там нет страшных WTFов (а может и не глянул - зачем проверять доверенных людей?) и смерджил. Если ты глянешь гуглоплюс Торвальдса, накануне майлстонов у него сообщения типа «уффф, все выходные мерджил 3000 коммитов». Ты хотя бы заголовки от 3000 коммитов прочитал бы за выходные? А он их еще и смерджить успел :3

можно было выпустить ядро в котором ваша сетевуха работает, но в ArchLinux так не принято...

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

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

Вот о руководстве и речь. Доверенные лица присылают 3000 патчей, это хорошо. Но где доверенные лица, которые всё это тестируют? У Торвальдса вообще есть хоть малейшее представление о QA? Представь себе, что Бил Гейтс или Стив Джобс руководили бы своими проектами подобным образом.

Поставить ядро linux-lts ещё не советовали? Ставится независимо от обычного.

Enhancing_Arch_Linux_Stability

P.S. такое в Arch-e вообще часто бывает, когда после pacman -Syu система полностью сломана?

стандартная ситуация, если настройка сколь-нибудь не дефолтная.

Я всегда перед этим читаю Arch-news

Поставить ядро linux-lts ещё не советовали?

А остальной софт с ним совместим? Почему LTS лишь ядро, а не вся система? Вот в Ubuntu есть обычные релизы всей системы и LTS.

А остальной софт с ним совместим?

Консольный — думаю, да. В иксах... Кстати, есть nvidia-lts.

Почему LTS лишь ядро, а не вся система?

Bleeding edge. Были попытки сделать archserver, но угасли, — видимо, слишком мало энтузиастов. Те, кому нужна на самом деле стабильная серверная система, используют другие дистро.

ядро linux-lts ещё не советовали?

От linux-lts больше зла, чем пользы. Весь арчь заточен под новые ядра, а там 3.0. Плохой совет.

В тестинге linux-lts-3.10.12-1

От linux-lts больше зла, чем пользы.

В чём выражается зло? Есть реальный опыт?

комент был мой, только с другой машины

Да много.. например в моей текущей конфигурации начинают лагать иксы (черные квадратики вместо шрифтов) видево - xf86-video-intel; когда начинал пользоваться арчем, были проблемы с ядром, посоветовали linux-lts - ядро при загрузке через раз уходило в панику, из-за сетевухи (как бы не соврать, но помоему как раз как у ТС). Это, что сходу вспомнилось.

Иксы вроде на сервере ни к чему. Кстати, в репах есть ещё пакеты -lts, например

A kernel module for Realtek 8168 network cards for linux-lts

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

В тестинге linux-lts-3.10.12-1

А на багзиле лежит патч решающий проблему ТС'a. Проблем-то поправить PKGBUILD и пересобрать пакет для ядра. Это если очень надо 3.11. Если не надо - то откатить ядро на предыдущее. А linux-lts из testing - не нужно.
Тут автор не проблему решает, а ищет сочувствия и понимания. Его предали, и он пытается понять - почему.

Иксы вроде на сервере ни к чему

Arch на сервере ни к чему. А ТС иксы нужны, у него десктоп.

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

Ты не тот дистрибутив выбрал. Арчеюзеры - это люди понимающие что такое bleeding edge и чем это грозит. Use Debian, Luke.

Тут автор не проблему решает, а ищет сочувствия и понимания. Его предали, и он пытается понять - почему.

Я тебе уже сказал, что попробую откатить ядро вечером. Ты не расслышал, не прочитал? А сочуствие и понимание мне не нужно, меня интересует лишь стабильность системы.

Арчеюзеры - это люди понимающие что такое bleeding edge и чем это грозит.

Что же такое bleeding edge? Нестабильный софт, по чьей-то наивности называемый стабильным?

Я тебе уже сказал, что попробую откатить ядро вечером

OK, извини. На случай, если пакман не схоронил старое ядро, вот предыдущие ядрышки в реинкарнации AUR от наших китайских друзей: x86_64 и i686. Копируешь ссылку, качаешь и ставишь через pacman -U.

bleeding edge - это самый свежак который потыкали и вроде оно не падает. Оттого и появление всех свежих фишек очень быстро. Обратной стороной является то, что если ты маргинал с редким железом, то ты рискуешь нарваться на багу, которую кроме тебя увидеть некому.

testing арча это полный Bleeding edge во всей красе, stable - это то, что не падает при загрузке и запуске.

А тебе я уже выше написал, что Debian(Ubuntu) твоё всё, если ты не можешь сам разобраться с вылезшей проблемой в свежем софте и можешь только что плакать на ЛОРе что «айвай усё сломали гады!!1111одинодин»

bleeding edge - это самый свежак который потыкали и вроде оно не падает.

«потыкали и вроде оно не падает» никак нельзя называть стабильным ибо это заведомая ложь.

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

У меня вовсе не редкое железо. Просто nobody cares.

Просто nobody cares.

И ты такой же, раз пришел нытье на 3 страницы разводить сюда

Люди пишут, я им отвечаю. У тебя с этим проблемы? Хочешь об этом поговорить?

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

У меня вовсе не редкое железо.

Отстуствие движняка говорит об обратном.. баг заметил парень из арча, когда 3.11 было еще в testing. Он же открыл Bug 61291 на багзилле и отписался в linux-netdev. А в ответ тишина. Кто-то поблагодарил его за патч. Ты третий? У всех других тысяч пользователей этого железа сломалась сетевуха и им нет дела? Если так будут идти дела, возможно это еще долго не починят. Забавно начинается сообщение того парня в нетдев:

Bug: Linux kernel v3.11.0 for my 10-year-old machine

Описанная тут проблема является критической.

Судя по https://bugzilla.kernel.org/show_bug.cgi?id=61291, она проявляется только у пользователей определенных сетевых карт -> в масштабах ядра она НЕ критическая(но важная, да).

Importance: P1 high

Так что не прав тут ты.

Тестированием должны заниматься оба.

Не знаю как в Арче, а вот у нас в генте на unstable-ветке я б тебе сказал «enjoy your unstable». А вот на stable-ветке по шапке бы уже прилетело Gentoo Kernel Team :-)

В Арче тебе никто стабильность и не обещает. Хочешь стабильность - юзай Дебиан.

Нет в арче понятия stable:) Есть bleeding edge, а есть bleeding bleeding (testing) edge:)

такое в Arch-e вообще часто бывает, когда после pacman -Syu система полностью сломана?

Каждый раз.

Откатил до 3.10.10-1

После отката сеть заработала. Прямо Совок какой-то.

Интересно, как долго придётся ждать исправления.

Так арч production-stable дистрибутивом никто никогда и не называл.