LINUX.ORG.RU
ФорумTalks

Дебианушки мяты и сложены :-(

 ,


0

2

По материалам OpenNet.ru


Претензии к инфраструктуре касаются излишне усложнённого сборочного стека, необходимости ждать до семи часов пока загруженный пакет можно будет установить, устаревших асинхронных механизмов взаимодействия в сообществе и отсутствия инструментов для обработки больших изменений. По мнению Штапельберга, некоторые элементы инфраструктуры сильно устарели. Например, в Debian применяется тянущийся с 1994 года устаревший механизм отслеживания ошибок (debbugs), который не используется нигде, кроме Debian и проектов GNU, завязан на отправке сообщений через email, а через Web (bugs.debian.org) доступен в режиме только для чтения.

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

Огромным демотивирующим фактором также является затягивание принятия патчей. Отправка изменений для рецензирования сводится к заведению уведомления о проблеме (bug report), к которому прикреплён патч. Но так как на время рецензирования не накладывается никаких жёстких рамок, данный процесс может протекать очень медленно. Случалось, что сообщение об утверждении патча приходило спустя несколько лет с момента его предложения. Отсутствуют должные средства для отладки пакетов (не все пакеты доступны с отладочной информацией).

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



Как еще убунта в таком бардаке выживает?

Deleted

Последнее исправление: RTP (всего исправлений: 1)

Кажется, они начинают что-то подозревать.

meliafaro ★★★★★
()

Всегда интуитивно чувствовал, что Дебиан - переусложнённая помойка, вот и пруфы

Deleted
()

Как еще убунта в таком бардаке выживает?

Мне кажется, что Убунта скоро станет лфсом, если так будет продалжаться. Зато, мы может быть будет радоваться наработками от фантазёров из Каноникла

xeneloid
()

Например, в Debian применяется тянущийся с 1994 года устаревший механизм отслеживания ошибок (debbugs), который используется нигде, кроме Debian и проектов GNU, завязан на отправке сообщений через email

Наоборот. эта фишка очень хорошая. Человек, который понял, как правильно отправлять багрепорты через email и прочел, какие теги надо указывать, уже не будет засорять BTS бессмысленным флудом. Если снизить порог прохода в BTS, то там все превратится в свалку. Кто-то не удосужится прочитать man и сразу в BTS побежит.

Zubok ★★★★★
()
Последнее исправление: Zubok (всего исправлений: 2)

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

papin-aziat ★★★★★
()

Возможно, Debian заслужил репутацию стабильного дистрибутива не вопреки этим странностям, а благодаря.

Мало кто хочет тянуть наследие годов и делать прогресс плавно. Многие хотят выкинуть существующее и переписать заново, не думая о том, что и почему сломается.

Pravorskyi ★★★
()
Ответ на: комментарий от t184256

Там очень много читать, но ты пишешь о том, что где-то подолгу не фиксят баги? Я конкретно про механизм BTS говорю. И тут же ни армия клоунов не поможет, ни ее отсутствие. Другая проблема. Я сам не люблю, когда тормозит сопровождающий. Но причины могут быть разными. Иногда сопровождающие являются одними из разработчиков пакета или просто хорошо в нем ориентируются, а есть такие, которые настолько уперты, что злости не хватает.

Zubok ★★★★★
()
Ответ на: комментарий от petyanamlt

Да пусть сборщики страдают, пользоватлям пофиг.

Ведь качество дистрибутива никак не страдает от того, что малейшее изменение требует титанических трудов.

kirk_johnson ★☆
()

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

Вот она - тщательная отладка!

xwicked ★★☆
()

Давай линки, и не выдирай из контекста.

И что? Порвалься, да и хрен с ним.

https://www.opennet.ru/opennews/art.shtml?num=50289

Майкл Штапельберг (Michael Stapelberg) объявил о прекращении сопровождения в Debian поддерживаемых им пакетов из-за недовольства текущим состоянием инфраструктуры проекта.

mandala ★★★★★
()

Например, в Debian применяется тянущийся с 1994 года устаревший механизм отслеживания ошибок (debbugs), который не используется нигде, кроме Debian и проектов GNU

Да. Это жесть какая-то для мазохистов...

fornlr ★★★★★
()
Ответ на: комментарий от Zubok

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

Поддержка, например, full-disk encryption без отдельного /boot в инсталляторе, для которой надо было добавить одну строку и убрать другую, не добавлялась так долго, что стала неактуальной. Вот это по-дебиановски, пересидеть проблему.

t184256 ★★★★★
()
Ответ на: комментарий от alpha

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

Deleted
()
Ответ на: комментарий от Quasar

так федору активно рихтуют, жаль что с трудом пропихивают невидь-блоб, но Фороникс вещает о скором решении данного вопроса.

Deleted
()

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

А почему должно быть как-то иначе, если это не коммерческий проект? От того, что введут «жесткие рамки», джаст-фор-фан вдруг ни с того ни с сего превратится в работу по найму?

seiken ★★★★★
()

Бред школьника 7 класса. Предлагает ввести корпоративные дедлайны? Дополнительный контроль за маинтейнерами? Чё за бред вообще? Дебиан поэтому на голову выше всех именно потому что там за идею в первую очередь. И вот ещё, маинтейнеры дебиана это и есть основное сообщество и оно пилит пакеты в первую очередь для себя, внезапно да? Проблемы есть и они озвучены, те же патчи, но всё в одну кашу смешивать не надо.

К слову забавно читать как подробно расписывают «проблему» с rsync и откуда то знают мотивацию сопровождающего не включать debhelper язливо говоря «из-за своих частных предубеждений»

И далее пустозвонное ахахаха «что мешает повышению уровня абстракции системы сборки пакетов и усложняет инструментарий» без уточнений, чем сопровождающий усложняет инструментарий не используя debhelper?

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

Deleted
()

Сервисы неюзабельные, тулзы мерзкие, обои скучные. Люто печёт от всяких стречей, сидов и прочей хероты вместо натуральных чисел, как в нормальных дистрибутивах.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Печёт не пользуйся, в чём проблема?

Deleted
()
Ответ на: комментарий от Deleted

так федору активно рихтуют

И столь же активно наваливают сверху.

Quasar ★★★★★
()
Ответ на: удаленный комментарий

что мешает вместо того что бы бубнить встать в ряды сопровождающих?

Сколько лет и всё нормально

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

alpha ★★★★★
()
Ответ на: комментарий от Deleted

А я еще и вышивать умею! (С)
Осталось только швейную машинку прикупить %-/

Deleted
()
Ответ на: комментарий от alpha

Ты такая интересная. Ну протухли мечты 30-летних идеалистов в 2000х годах. Или сколько там всем дистроклёпам было? Последние курсы универов/колледжей? 22-25?

А теперь дом, дети, машинки, путешествия, опять же обленились. Диван, панель в 75", ****неразборчиво**** ОС для серфинга с дивана... А то еще чего хуже, гараж оборудуется в мастерскую и понеслась столярка по ночам!

Deleted
()
Ответ на: комментарий от alpha

На грядущие проблемы с опакечиванием всего софта в пределах дистра намекали все. От ламеров, до профиков как Яблочных, так и МСовских.

Нет, 20 лет шли своим путём. Ну вот, созрели плоды, только тухлятинкой отдают и явно не дуриан на вкус.

Deleted
()
Последнее исправление: RTP (всего исправлений: 1)
Ответ на: комментарий от Deleted

Я написала выше, дело вовсе не в устаревании идеи опакечивания. Если глянуть на самые «хипстерские» технологии, как только они доходят до чего-то серьезного, они начинают пакетировать. Что helm для kubernetes, что роли для ansible. Это естественная задача.

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

В итоге приходит к тебе разработчик и говорит, слушай, у нас так много приложений, а вот бы нам придумать такой формат чтобы описывать их версии, зависимости, и post- и pre-install хуки и вот это всё? И ты так, да, вот бы, действительно, придумать..

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

В итоге приходит к тебе разработчик и говорит, слушай, у нас так много приложений, а вот бы нам придумать такой формат чтобы описывать их версии, зависимости, и post- и pre-install хуки и вот это всё? И ты так, да, вот бы, действительно, придумать..

Не-а. И ты смотришь вот есть такие идеи там, такие там. Но всё равно это не залезет в твою задачу. И ты делаешь новое на основе этих идей.

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

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от alpha

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

ptarh ★★★★★
()
Ответ на: комментарий от Deleted

Меня шатает из стороны в сторону. На прошлой работе была «старичком» ругающим хипстеров, на текущей - «старички» ругают меня :)

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от fornlr

Не-а. И ты смотришь вот есть такие идеи там, такие там. Но всё равно это не залезет в твою задачу. И ты делаешь новое на основе этих идей.

Если бы «на основе» это было бы развитие.

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

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

Там можно придти с Fedora Packaging Guidelines, вырезав предварительно из них все упоминания Fedora, rpm и заменив package на image, и ты будешь гуру, открывателем путей и решателем проблем.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Ну расслоить-то линукс всё равно пришло время, нет? Ну куда годиться, если для обновления плеера нужно обновлять всю систему?

papin-aziat ★★★★★
()
Ответ на: комментарий от alpha

В прошлой конторе переходили на контейнеры и облака. И был показательный случай.

Приехали гугловые архикторы продавать нам гуглооблако.

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

Один из разговоров:

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

- что значит из абы чего?

- ну вот например одни php 7.2.3 хотят, другие 7.2.1, а третьи 5.2 ещё не вынесли. Напихают себе этого добра в базовый слой и пилят приложения на нем.

- а у нас разработчик не выбирает базовый слой. У нас команды есть - одни делают базовый уровень оси, другие выпускают слои платформы. Системная Java-команда выпускает java-слои, и все приложения должны на одном из этих фиксированных слоев сидеть. Тащить в контейнер обновления извне в обход этих команд запрещено.

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

Здравствуйте, майнтейнеры и packaging guidelines - будущее контейнерной разработки. Для половины маководов-разработчиков это абсолютно новая концепция, откровение.

alpha ★★★★★
()
Ответ на: комментарий от papin-aziat

Ну если посмотришь на flatpak, modularity и тому подобное, то варианты расслоения есть.

И конечно вопрос с устаревшей инфрой это проблема, и в дебиане, и в ядре, и в федоре.

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

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

Такое ощущение часто, что в IT преимущественно наркоманы: одни дураки лепят оси на пакетных системах и потом удивляются, когда они по грузом подпорок разваливаются при апдейтах/апгрейдах/любом шаге в сторону, а другие готовы деплоить любой hello_world чуть ли не с целой операционкой впридачу. Третьи дураки пишут десктопные приложения на брузерах, этим особая премия полагается.

а у нас разработчик не выбирает базовый слой. У нас команды есть - одни делают базовый уровень оси, другие выпускают слои платформы. Системная Java-команда выпускает java-слои, и все приложения должны на одном из этих фиксированных слоев сидеть. Тащить в контейнер обновления извне в обход этих команд запрещено.

Поздравляю их, они изобрели билдпаки cloud foundry. Через год-другой очередной школьник дойдет до того же решения под другим соусом.

ptarh ★★★★★
()
Ответ на: комментарий от alpha

Ну если посмотришь на flatpak, modularity и тому подобное, то варианты расслоения есть.

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

papin-aziat ★★★★★
()
Ответ на: комментарий от ptarh

Поздравляю их, они изобрели билдпаки cloud foundry

Ты путаешь кто кого изобрел в данном случае. Но дело не в этом.

Технология не играет роли, формат спек-файла не играет роли, yaml, xml или баш скрипты не важно.

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

От того что Fedora перейдет с rpm на deb или хоть на образы для flatpak она не перестанет быть дистрибутивом и не потеряет своей ценности. Главное подход, принцип.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

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

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

ptarh ★★★★★
()
Ответ на: комментарий от ptarh

мир интересует институт линуксячьего мейнтейнерства

мир за этим в очередь выстраивается

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

В шутке про Fedora Packaging Guidelines реально только доля шутки. Во всех прошлых конторах где я работала, они конечно думали что платили мне за devops и CI. А по факту именно за то, что я принесла им эту перспективу - большого проекта, с организацией, с приемами работы, которые учитывают наличие другой разработческой деятельности кроме написания куска кода.

devops вообще как явление - это мечта о подобном институте. Только в исполнении бестолкового энтерпрайза получаются одни фантики вместо конфет.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

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

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

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

Может быть. Так и в исполнении линуксовых дистров выходит г**но какое-то. Я использовал, я знаю ¯\_(ツ)_/¯. Чему тебя может научить неумеха, это занимательный вопрос.

ptarh ★★★★★
()
Ответ на: комментарий от ptarh

Так и в исполнении линуксовых дистров выходит г**но какое-то

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

Да-да, 20 лет прошло, а системы установки блобов силами вендора нет.
Зато в репазитарии аж целых 60тыщ пакетов.

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

Короче, претензий много накопилось за 20 лет к современной модели дистрибуции этого ихнего маинтайнерского Линукса 🤢

Deleted
()
Ответ на: комментарий от Deleted

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

Только запуская Синаптик? Ну это уже что-то.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.