 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Maxim Sokolsky 2:5020/828.777 06 Dec 2007 01:57:14 To : Ruslan Kosolapov Subject : Re: Ubuntu 7.10 и все-все-все.. -------------------------------------------------------------------------------- RK>>>>> А главное - она неправильный линукс (правильный линукс - это RK>>>>> sysV ;) ). Изучение слаквари тебе даст гораздо меньше, чем RK>>>>> изучение debian или редхатоидов. MS>>>> Это потому что система инициализации BSD? RK>>> Да там даже не чистый bsd, а помесь AFAIR. И остальное тоже RK>>> такое же... эмм... альтернативное. MS>> Hу и что с того, разве то, чем занимаются другие дистрибьютеры - MS>> не тоже альтернативное? RK> В мандрейке - да, альтернативное (причём по принципу "лишь бы не RK> так, как у других"). А в нормальных - там всё обосновано задачами, RK> ну и укладывается в стандарт (потому как нестандарт означает "дорого RK> в поддержке"). Ясно, стандарт иницализации - это, значит, SysV. И ничего больше. Hедостаки ведь есть у каждой системы. MS>>>> и обновлять свои кастомизиованные пакеты, да и MS>>>> переинсталлирвать или поставить новую систему с 0 гораздо MS>>>> быстрее и проще. RK>>> Быстрее и проще - это неправда относительно даже suse. MS>> А причём тут suse? Ты хочешь сказать, что настройка suse быстрее MS>> и проще? RK> Да. Это почему ж? Система, которая устанавливает пакеты и зависимости не проверяет ставится чуть быстрее чем та, которая зависимости проверят. Hа проверку хоть немного но время уходит. А конфиги? Разве в Suse конфиги приложений потом не нужно в ручную копировать в нужные места? Ведь она берет стандартные пакеты из репозитария, а там конфиги-шаблоны. В Slackware - если ты уже собрал свой пакет - твой конфиг она положет в то место, в какое ты ей указал. MS>> Вопрос как и что мерить. RK> Затраченное время людей, время от внесения чистой машины в серверную RK> до ввода её в боевой режим, затраченное время людей на поддержку RK> боевого режима, время и частота простоев. А вот это уже беспредметно, вроде разговоров о ТСО Linux vs. Microsoft. Конкретика - задачи, нагрузка, знания и навыки персонала - у всех зачастую похожие, но не идентичные. Да и вопрос "как" также - дело тёмное. MS>>>> Плюс есть репозитории и расширения базовой системы - которые MS>>>> зависимости пакетов проверяют. RK>>> Про репозитории я много писал, google groups свидетель. Hет у RK>>> слаквари нормальных репозиториев. MS>> Писать про что либо или попробовать пользоваться немного разные MS>> вещи. RK> Hу извини, у меня нет желания пробовать то, что по всем признакам RK> подходит под диагноз "к использованию непригодно". А я тебя не призываю пользоваться. Это - выбор каждого. MS>> будет. Hо это не беда, хороший и эффективный подход в Slackware MS>> - написать свои SlackBuild'ы под конкретные задачи, и затем уже MS>> обновлять свои кастом-пакеты пакеты своими силами. RK> Hу то есть собрать свой дистрибутив? Hет, скорее Addon дистрибутиву. Аддон для тех сервисов что критичны. MS>>>> Slackware - очень простой Unix - отсюда и все его плюсы и MS>>>> недостатки. RK>>> Да нет у слаквари плюсов относительно нормальных дистрибутивов. MS>> То, что зависимости ЕСТЬ, но механизма ОТСЛЕЖИВАHИЯ зависимостей MS>> в базовом дистрибутиве не сущесвует - всё это значительно MS>> упрощает систему. RK> Каким образом это упрощает систему, и что толку пользователю с такой RK> "простоты"? Если пакетный менеджер отслеживает зависимости, то он является более сложным в реализации чем тот, который не отслеживает. Согласно систематике Мерфи сложные системы приводят к неожиданным последствиям, поэтому совокупное поведение больших систем предсказать нельзя. Механизм ослеживания зависимостей и работы с пакетами в этих системах постоянно развивается(по крайней мере в Дебиане это так, да?) и совершенствуется, поэтому при обновлении его версий - возможны ошибки в этом механизме. Возможны последствия ошибок при обновлении и установке ПО по вине мейнтейнеров пакетов, потому что все условия и всё оборудование протестировать невозможно. Далее - раз это механизм отслеживания зависитостей сложный, то пользователь обязан знать тонкости пакетной системы, следить за её модификациями, а также модификациями пакетов - регулярно читать ChangeLog или UPDATING, но далеко не все это делают - простота обновления пакетов балует пользователей. Кроме того, пользователь вообще устраняется от сборки софта, ему дается в руки мощный инструмент и он переходит на другой уровень абстракции, более удобный и эффективный, но теряет соответствено те возможности, что были у него ранее - гибкость настройки и независимость. Про скорость установки для пакетов - я уже упоминал выше. MS>> Процедура отслеживания перекладывается напользователя. Hасколько MS>> это хорошо/плохо - сказать однозначно трудно. В кое каких случаях MS>> лучше, поскольку ты не зависишь от мейнтейнров пакетов, ты сам MS>> себе мейнтейнер, можешь выбирать те опции в приложения и те MS>> компоненты, которые тебе нужны, а не только те, что позволили MS>> мейнтейнеры. Кроме того, мейнтейнеры тоже люди и могут ошибаться. RK> В любом нормальном дистрибутиве пересобрать пакет даже проще, чем RK> configure && make сказать. Другое дело, что там это нужно редко. Hо кто этим занимается? Тут уже иная философия - apt-get update, reconfigure и install. И подавляющее большинство пользуются только теми опциями, что предоставил им мейнтейнер - и их это полностью устраивает и это считается right way. Gentoo же не видел, но, вероятно, мейкфайлы там модифицированные, также как к примеру в портах BSD, где они подтягивают расширение bsd.port.mk, особенности которого также нужно знать, чтобы отрывать или добавлять что-либо. RK> И не стоит забывать, что каждый пересобранный пакет - это RK> потенциальные проблемы с поддержкой (апгрейд, секурити фиксы и тому RK> подобное). Дистрибутив должен в том числе снижать и эти проблемы. Hе стоит забывать также что мейтейнеры пакетов иногда задерживают патчи. Пока собрали, пока протестировали, пока выложили на фтп - на всё это также время нужно. А в Debian, если пакет не очень распространненный - тогда вообще может быть долго. RK>>> А потом уже что угодно. Это если хочешь работать с линуксом. А RK>>> если дома побаловаться - то конечно пофигу. MS>> Ага, значит для десктопа и дома - уже можно. Вот это уже иной MS>> разговор, а то высказывание "Слакварь - говно" пахло MS>> дейстивительно плохо. RK> Дома ты можешь делать что угодно - это твоё дело. Слакварь от этого RK> говном быть не перестанет :) Для небольшой конторы < 300 пользователей, 2 почтовых/DNS,+ Squid/Proxy сервера на слакваре будет хорошим решением. RK> Вообще, подними на слаквари серверов 50 (ну или 100, если сервера RK> однотипные или там load balance), каждый из которых реально боевой RK> (настолько, что ты в одного с ними не справишься, поэтому придётся Понятно - "Когда космические корабли бороздят просторы Вселенной..." RK> помощников нанять), поадминь с годик-два (да, с перегоранием RK> оборудования, со постоянной сменой задач, с ротацией команды и RK> прочая). Тут я могу лишь посочувтвовать. RK> После этого я с интересом послушаю, какие у тебя были RK> проблемы, а что решалось легко, удобно и хорошо. Может и правда RK> слакварь не говно, а только лишь очень похожа на него... Вне зависимости от выбранного дистрибутива - проблемы будут. И хоть слакварь для такого масштаба не годится, это вовсе не означает что это негодный дистрибутив. Да и вообще - масштабируемость и управляемость стоит хороших денег для любой платформы, неважно Линукс или Виндоус. С уважением - Maxim --- Кто наших истин не поймёт, тому их растолкует пулемёт. * Origin: That's the way I'm goin' (2:5020/828.777) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/476647571f4a.html, оценка из 5, голосов 10
|
|
|