Debian vs systemd

У меня такое ощущение, что ты никогда не занимался/не в курсе про разработку ПО:-) Критические ошибки вылазят в стабильных релизах, чего уж говорить о тестинге?

Критические ошибки вылазят в стабильных релизах, чего уж говорить о тестинге?

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

http://without-systemd.org/wiki/index.php/Main_Page#Free.2FOpen_Source_Operat...

Выбор на этих двух дистрах не заканчивается.

Кривой какой-нибудь юнит или сервис. Адын.

То есть когда в последний раз установщик Debian (разумеется в testing) не мог записать груб виноват в этом был груб, а когда из установщика не поднимались иксы виноваты в этом были разумеется иксы. Логика тут и рядом не валялась.

Лично я за то, чтобы /etc/mtab вообще выкинуть к херам, а старый софт пофиксить.

фиксить сам будешь?

Кривой какой-нибудь юнит или сервис. Адын.

И что?

В результате, у меня все заработало через 20 минут

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

2sehellion

по багам не ходил, но обычно помогает установка минимального stable с последующим прописыванием реп testing и обновлением до него

я на тестинге обычно обновлялся до 7й версии просто. Сейчас я на old-stable и отдельно решил посмотреть в виртуальной машине на новые грабли.

2Chaser_Andrey

1. Testing. Ты же понимаешь, что это значит?

2. Уже пофиксили.

1. Раньше Testing работал нормально и не было идиотских проблем - сидел с 5й по 7ую версию на тестинге и все ок было. Система пережила «хардварный переезд». Бывало издевался над системой, но она все равно была устойчивой к моим рукам. А вот скачал чистую и новую, так на тебе нежданчик.

2. Ещё вчера пофиксил, просто осадок остался - захотелось поделиться своей грустью с остальными.

Так что это не баг systemd, а оплошность мэнтейнера/девелопера Debian.

да согласен. Но можно допустить возможность, что systemd не так просто сопровождать? + см. ниже

2MyFreedom

Пакеты из Debian Unstable автоматически попадают в testing дистрибутив, когда выполнен список требований:

Пакет находился в «unstable» как минимум в течении 2-10 дней (в зависимости от срочности загрузки).

Пакет был собран для всех поддерживаемых testing дистрибутивом архитектур.

Установка пакета в testing не сделает дистрибутив неустанавливаемым.

Пакет не добавляет новые критические ошибки.

Как минимум 2 требования из 4 провалили

+1 - Вот это самое и удивило. Критикал баг, а исошник выкатили и даже не проверили в виртуалке работоспособность.

2Gu4

Так вот почему, у меня не заработала установка testing на прошлой неделе. Правда, я вместо того, чтоб ныть на форуме установил stable netinstall и обновил.

В шапке темы по ссылкам уже и решение предложено было. Не отходя от кассы и пофиксил. А у вас слишком длинноватое решение получилось.

2Pavval

Сижу на тестинге с systemd уже минимум год (или сколько там systemd в тестинге живет?) и нихрена не понимаю, как так можно было отрастить такие кривые руки.

Шаги воиспроизведения:

1. Скачать amd 64 net install iso-шник

2. Создать образ в VMWare

3. Установить систему из образа.

4. Попытаться загрузится и получить сообщение о freezing execution (см. пост от Chaser_Andrey с логом)

2fornir

Я сразу же в поиске нашёл на багтрекерах случаи. А ты рассказывай дальше про стабильный Debian Testing.

Я поделился ЛИЧНЫМ опытом и впечатлениями. Раньше в testing можно было нормально работать, а теперь я вообще не уверен в этом.

2Quasar +1

Devuan

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

2Spoofing

ставь линукс, например CRUX, или Slackware, там таких проблем нет.

Вот как раз подумываю перейти в вероисповедание святого Патрика. На запасном пути FreeBSD, LFS.

2hateyoufeel

Это настолько страшная ошибка, что даже emergency shell нельзя дать?

+1 - Мне бы к single user mode получить доступ, а там почти любую систему оживлю.

2kirk_johnson

Поэтому мы повесим систему сразу, намертво и без recovery shell'а. Отличная логика.

+1

2Manhunt

+1

2all

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

И ничего. это снапшот, это не преальфа/пребета/RC.

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

Апстрим или ментейнер пакета пусть фиксит. /etc/mtab - это устаревшее дерьмо мамонта. Сколько ещё лет его тащить?

Апстрим

зачем ломать то что работает?

ментейнер

часто вообще не разработчик.

/etc/mtab - это устаревшее дерьмо мамонта. Сколько ещё лет его тащить?

сколько нужно.

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

наверное на десктопе разработчика оно загружалось :)

зачем ломать то что работает?

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

Объявляли и выпиливали из /proc ряд сущностей, /dev сделали динамичной, чем поломали логику части программ, просто потому что устройства не существовали «на всякий случай». Убирали устаревшие системные вызовы в мажорных релизах ядра. Хотя всегда мог найтись старый софт, который их юзал.

Это - эволюция. Нормальный процесс.

нужно

Ок. Кому нужно?

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

Если они не вредят то почему бы и нет? Поттеринг сломался из за поддержки SysV init?

Ок. Кому нужно?

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

Дебиан не пробовал, но альт, зюзя и шляпа с systemd проблем ни при установке, ни в работе не вызвали.

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

Пункты 1 и 2 очевидно не нарушены

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

Можно ссылку? На официальный сайт. И не на http://www.debian.org/devel/testing там всё именно так, как я написал. А то сильно похоже на выдумку в оправдание

По твоей ссылке все именно так как я описал, только еще более четко и ясно

Долго ещё ждать, когда это будет требованием, что бы /boot/vmlinuz был линком на /usr/sbin/systemd ?

Слишком толсто.

Толсто-нетолсто, а к тому идёт. Помяните мои слова через пару лет.

Допустим, что твои слова оказались пророческими.

Если решение от Леннарта будет более современное, архитектурно продуманное, как сейчас systemd, то почему нет? Я - за прогресс.

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

Может стоит пойти и почитать?

Он не должен содержать ошибок, мешающих выпуску и которые не содержатся в версии пакета, уже находящейся в тестируемом выпуске

вообще, если пакет содержит открытые ошибки, мешающие выпуску, он не попадет в тестируемый выпуск

Беда в том, что де-факто у нас теперь 2 ядра. Pid 0 и pid 1.

То, с чем всегда боролись в ядре, а именно впиливания туда всего и вся подряд, лёня решил реализовать в pid 1 (в pid 0 его не пустили).

Прогресс ли это — я не уверен. Но чую пятой точкой, что придёт время, когда pid 1 восстанет и захочет стать pid 0. ;)

Гражданин, расскажите подробно, с чем конкретно вы не согласны и что вы хотите от меня? Пока я вижу что вы либо не читали текст по ссылке, либо не читали мое сообщение.

Читал текст по ссылке, читал ваше сообщение, ваше сообщение высосано из пальца, что подтвержадают цитаты из статьи по ссылке, повторю:

Он [пакет] не должен содержать ошибок, мешающих выпуску и которые не содержатся в версии пакета, уже находящейся в тестируемом выпуске

Как это можно трактовать «Пункт 3 означает, что нет конфликтующих зависимостей»??? Про зависимости тут вообще ни слова, выпуск - это стейбл, очевидно, что баг, из-за которого нельзя даже установку запустить, мешает выпуску. Ну и так далее. Из-за любви к дебиану разум помутнел чтоли?

Как это можно трактовать

Гражданин, а свое собственное сообщение вы читали? вот это вот? очевидно что нумерация шла по вашему сообщению, а не по документации debian.

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

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

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