Pull to refresh
243
0
Микаел Григорян @temujin

BigData

Send message

Конечно интересно.

И форум был что надо. И биржа запросов интересная.

Какая там фирмварь, какой http сервер? Так проще уязвимости искать.

Вы совершенно правы! На 3 порядка. Исправлено. Спасибо, что заметили.

Если внимательно читать доки emerge и porage, следить за апдейтами eselect news read, никакого ада не будет. Ну вот у меня был случай тяжелый. Изначально система собрана --no-multilibs без 32-битных совместимостей, полностью 64-бита. Когда пришло время из KDE 4 на Plasma 5 перелезать, обнаружилось, что прямой дороги нет. Апгрейд сценарий есть только для всех, кроме --no-multilibs. Пришлось сперва тщательно выпилить KDE 4, qt 4 и все зависимости, пересидеть на Mate а затем собрать Плазму.
Но это самый непростой случай был, в остальных случаях с зависимостями все норм.

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

Я скажу что меня на Генте держит. Во-первых, меня сильно досаждал каждый апгрейд, релиз новой версии дистрибутива. Изменений было столько, что первые пару дней надо было заново знакомиться с ОС-ю. Почему-то всегда слетал eth0, тут что почивший Mandrake, что Debian. Всегда апгрейд был неприятен. Генту раз установил и дальше в ус себе не дуешь, хоть 10 лет подряд. Только апгрейды накатывай. Про Arch, много хорошеего говорят, но я на нем не работал и сравнивать не могу.
Во-вторых, в Генту всегда была годная документация. А про оптимизации и т. д. Я не фанат этого дела. Ну и гибкость, та самая ненавязчивость о которой речь идет в статье.

А что-именно нестабильно работало? Я уже довольно долго на Генте и после Гейзенбагов с аудио наушниками ничего критичного не случалось. Сейчас правда KDE Plasma падает время от времени, но тут уж явно дело а Плазме.

Отвечу цитатой.


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

Что-то в этом есть, но я использую только парочку сервисов — pulse, иногда NetworkManager, но не сам systemd и не могу точно сказать.

Я хотел сказать, что позиция автора мне близка. Я за то, чтобы дистрибутивы не навязывали пользователю выбор <системная компонента> там, где этого можно избежать и предоставить пользователю решать самому. Журналирование бинарное. Как снести systemd не знаю. Скорее всего никак, но я его не использую, пусть меня поправят.

Это перевод. Gentoo один из популярных Linux диструбутивов. Systemd система инициализации вокруг которой много споров. Что именно похоже на «я не буду кашу»? Смысл статьи отражен в заголовке. Gentoo Linux предоставляет свободу выбора и не навязывает систему инициализации по примеру… да всех.

Не вполне согласен, так иногда говорят.

В оригинале автор писал distro. Я постарался это передать.

Такие исследования есть, но их крайне мало. Из них пара в ссылках. Выводы — за график, практика тоже — за график, крупные Open Source проекты в своей массе релизят именно так. Для небольших прикладных Unix-way утилит, вполне сойдет ad-hoc. Но где-то существует предел сложности проекта, когда пора менять стратегию. Граница линейкой не прочерчена, но она где-то проходит.


Вы знаете крупный OpenSource проект, в котором релизы не по оговоренному графику? Для меня только Apache веб-сервер непонятно как релизится а остальные — по расписанию.

Я имел в виду, что есть законченные рабочие продукты, у которых «цикл разработки» не предусмотрен и/или носит ситуационный характер.

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

А почему или-или? Все это, но также придерживаться графика. Убунту — 6 месяцев, Гном — 6 месяцев, KDE — 5 месяцев, и т. д. Для крупных проектов, так целесообразнее, а когда работа не велась, то и релизить нечего. Никто не предлагает, чтобы ping обновлялся каждые 3 месяца.

Я в выводах написал, что основная выгода от частых релизов для крупных проектов, в которых может быть коммерческий интерес у третьих сторон. Опять же есть оговорка, что когда мало изменений — график релиза не имеет смысла. И все же, тот же gzip иногда по несколько лет не давал о себе знать:


[ ] gzip-1.2.4a.tar.gz  1999-02-02 19:20    216K
[ ] gzip-1.3.9.tar      2006-12-15 03:44    1.6M

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity