Linux vs. FreeBSD

[Dragon7]

FreeBSD особый респект конечно,
правда из-за игрушек  и виндой приходится пользоваться :)

[pravilov]

to <bqq0408> - не Xenix конечно но тоже интересно
http://mfs.sunsite.dk/ <- Minix from scratch ;-)))

чисто практический взгляд
___________linux___________________|______________freeBSD
____за________|________против_____|________за_________|____против
___________________________________________________________________
_+_новый hard__|___________________|_+поддержка(15 чел)|_- нету MC
_+_много софта_|___________________ |+порты___________| - нет аналога linuxconf
_+_ipchains/tables|__________________|_+стандарт на разме_|
_+_SysV init_____|__________________|_ щение данных_____|
_+_rpm________|_______________ --> |_ <--- +CSV_________|
_+_lilo_________|___________________|+более широкие воз|
______________|___________________| можности работы с |
______________|___________________|_разделами________|
______________|___________________|+ возможность выбора|
______________|___________________|изначально high security level|

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

[Holy Joly Sergik]

Кто сказал, что в FreeBSD нету MC? /usr/ports/misc/mc, /usr/ports/misc/mc-light
Да и позвольте поинтересоваться что такое linuxconf?

[ihc]

linuxconf == срань Господня и позор на наши красноглазые головы.

Возможно, это уже звучало, если прочитал невнимательно -- сорри. У меня несколько "за" линух, и все они чисто прагматические.

1) очень плотно приходится работать с Oracle. Который под *BSD идёт условно, и, когда идёт, идёт очень криво (можете поверить на слово -- у нас тех.статистика нешуточная и есть основание так говорить)

2) я так и не смог понять, как в *BSD получить возможности, аналогичные iproute2. Поясняю на простейшем примере. Есть сервер А с тремя интерфейсами, один локальный, два смотрят в _разные_ AS (одна -- Питер, вторая, скажем, -- Лондон). Запрос от клиента Б может придти как через один, так и через другой внешний интерфейс. И уйти должен соответственно. В линухе это решается отдельными таблицами маршрутизации на каждый внешний интерфейс. А в *BSD?

3) порты сосут, сорри за прямоту. Каждый, кто использовал apt, меня поддержат, а остальные могут поверить на слово. Ещё одно основание -- я собираю пакеты как под Debian (deb), так и под ALT (rpm). И собирал в порты пару прог, по счастью, это занятие кинув, не углубляясь серьёзно. Порты как система сборки есть ничто иное как атавизм, коему место в учебниках истории.

А так -- система как система. Был бы apt под бздю, поставил бы поиграться, глядишь, занялся бы серьёзнее. Пока же смотрю иногда, утираю слезу и снова сажусь в линух.

[Belansky]

ihc
Много слов, но мало аргументации.

[mar]

1) ну, собственно, даже если не верить на слово - oracle официально поддерживает RedHat и компанию - это на сайте оракла паочитать можно, тут все верно.
2) во FreeBSDпо-моему, это можно и одним конфигом ipfw решить (а в open стоит нечто совсем замечательное, но я его не использовала, посему воздержусь от комментариев =))
3) маска-маска, я Вас знаю ;) ну я использовала и то, и другое и с портами мне как-то приятнее работать, думаю это личное ощущение. Работу с установкой пакетов (и отслеживанием зависимостей - а что еще собственно дает апт?) FreeBSD поддерживает. Кстати, apt в ALTlinux (ведь речь о нем?) имхо во много раз хуже, чем исконный под debian.

[ihc]

Belansky:
для меня хватает :)

mar:
2) как?
3) Проблема не только в установке, проблема в сборке. Для сборки пакета в порт и пакет нужно править независимые файлы и список установленных файлов в порту и пакете формируется по-разному. Это, в общем-то, ненужное дублирование порождает возможность ошибки. Если нужно дословно до файлов -- могу завтра в ночь поднять свои порты. Про установку также отдельная история. Если мне надо на маленький (<500Mb) раутер вставить, скажем, squid до кучи, то из портов это не сделать -- банально места не хватит, не говоря уже о том, что мне cc не сдался на раутере. Из пакейджей -- они не идентичны портам. Иногда фатально. Вот это больше всего убило -- то, что пакет, сделаный по make package не даст мне того же, что make install.
Про "кстати" -- хуже или лучше, понятия относительные. Что он не умеет такого из killin' features Дебиановского?

[Belansky]

ihc
для меня хватает
Кто бы сомневался... :)

[pravilov]

признаю, с mc перегнул палку , в остальном(рассматриваю только серверное применение) пока на стороне бээсдэ

[B o s s]

pravilov
поддержываю, бсд рулит!

[Holy Joly Sergik]

pravilov, а у меня и на десктопе неплохо, правда есть некотрые проги, заменителей которым я в никсах не нашел, например, FineReader ну и игры ясно-понятно (Microsoft Train Simulator очень люблю), поэтому приходится еще и Дас виндаз 45 :) на соседнем разделе держать.

[mar]

B o s s
лучше бы с аргументами ;)
pravilov
linuxconf - это такой всеобщий конфигуратор? тогда уж сразу - нет панели управления. Может это плюс, а не минус ? :)
ihc
так в явном виде же можно указывать что что-то пришедшее via такой-то интерфейс посылаем via что хотим куда хотим (это по пункту 2)
Что касается apt - ну не везло мне с alt-linux-ом (или меньше везло, чем с debian-ом). В последнем как-то чище зависимости отслеживались и реже (или почти не было) отваливалось из-за каких нибудь несовместимостей чего-то с чем-то. Конкретно уже не помню.
По поводу желания получить пакет, но аналогичный порту (то есть такой же новый - правильно?) - ну просто сначала обновляются порты, потом пакеты. Питоны - скалистые змени говорят так, потому, что привычки у них такие.
По поводу отсутствия места для компиляции портов - достойно размышления :) - предлагаю all высказаться.

[mar]

Holy Joly Sergik
для десктопов:
аналоги win-lin программ (http://linuxshop.ru/linuxbegin/win-lin-soft/table.shtml) (правда, там про Linuxб а не про BSD - но во-первых, никто не мешает использовать linux-программы под FreeBSD, а во-вторых, часто в этой таблице они (программы) общие)
Но про FineReader - заменители, кажется, и впрямь не очень :(
Про игрушки ничего не скажу - не знаю :) (хотя я уже по-моему писала, что некоторые у нас народ под wine запускал).
Но это все проблемы *nix вообще, а не Linux vs FreeBSD :)

[Holy Joly Sergik]

mar, из аналогов FineReader я могу вспомнить только Kaabooka (вроде так) из KDE, но в смысле распознавания текстов это такое у.е...
Про игрушки - в портах натыкался на Linux-версию Heroes of might and magic, но для установки необходим официальный CD, покупать не охота. А вообще чтоб немножко поиграть хватит и TuxRacer, однозначно рулит (почти как NFS :) ). Под wine можно, но эти пляски с бубнами, скажем - это не то чего хочет конечный пользователь.
Продаются специальные сборники Linux-игр, но их я не покупал, поэтому что это такое еще не знаю.

[ihc]

mar:

1) если не ошибаюсь, пришедшее via такой-то интерфейс является входящим пакетом, а входящие пакеты мне ни к чему разруливать в данном примере. Мне нужно, чтобы ответ на него ушёл через тот же интерфейс, что пришёл запрос. Или ipfw научился работать на уровне соединений и логики маршрутизации?

2) есть нестабильные репозитарии, как в Debian, так и в ALT. Количество unresolved зависимостей внутри репозитария в ALT меньше. Их там просто нет. При переходе с версии на версию -- граблей примерно поровну. Надо только иногда сдерживать гордость и не обновляться из Сизифа на сервере, если не знаешь брода -- для этого есть Updates. Иначе говоря, возможность != необходимость.

3) про пакеты/порты: проблема не в синхронизации портов с пакетами, а в том, что файлы порта -- это то, что установит make, а файлы пакета -- то, что описано в pkg-list. А то, что снесётся из системы, описано снова в Makefile. Это если не считать pkg-install и deinstall, которые тоже важны, но только в случае пакета. Потому как Makefile там, понятно, не отработает. Попробуйте собрать в пакет сервис, который традиционно (захардкожено) хранит базы в /var/servicename. То есть, плюёт на $prefix. И при этом при установке неплохо бы подтюнить скрипты для автозапуска. И делать это, как я уже говорил, придётся в двух, а то и трёх местах разом.

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

[strejiok]

Фрюша рулит!!! Без лишних слов ;))

[mar]

для желающих почитать о + и - пакетов и портов с точки зрения разработчиков FreeBSD - 4.2. Обзор установки программного обеспечения (http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/ports-overview.html)
(в связи

Преимущества пакетов
*Сжатый tar-архив обычно меньше, чем сжатый tar-архив, содержащий исходный код приложения.
*Пакеты не требуют никакой дополнительной компиляции. Для таких больших приложений, как Mozilla, KDE или GNOME, это может быть важно, в частности, если вы работаете на медленной системе.
*Пакеты не требуют понимания процесса компиляции программного обеспечения во FreeBSD.
Преимущества портов
*Пакеты обычно компилируются с консервативными параметрами, потому что они должны работать на максимальном количестве систем. При установке из порта вы можете изменять параметры компиляции для того, чтобы (к примеру) генерировался код, специфичный для процессора Pentium IV или Athlon.
*Некоторые приложения имеют опции времени компиляции, связанные с тем, что они могут или не могут делать. К примеру, Apache может быть настроен с широким набором различных опций. При построении из порта вы можете не принимать параметры по умолчанию, и задать их самостоятельно.
В некоторых случаях для одного и того же приложения будут иметься несколько пакетов для указания конкретных настроек. Например, Ghostscript имеется как пакет ghostscript и как пакет ghostscript-nox11, в зависимости от того, установили вы сервер X11 или нет. Такой тип грубой настройки возможен при использовании пакетов, но быстро становится недостижим, если приложение имеет более одного или двух параметров времени компиляции.
* Условия лицензирования некоторых дистрибутивов программного обеспечения запрещает распространение в двоичном виде. Они должны распространяться в виде исходного кода.
* Некоторые не доверяют дистрибутивам в двоичном виде. При использовании исходного кода вы по крайней мере (теоретически) можете прочесть его и попытаться найти потенциальные проблемы самостоятельно.
* Если у вас есть собственные патчи, вам нужен исходный код для того, чтобы их применять.
* Некоторым нравится иметь исходный код, чтобы его можно было смотреть и хакать, заимствовать из него (конечно, при разрешающей лицензионном соглашении) и тому подобное.

от себя - нехватка места на диске - это, конечно, аргумент. Но преимущество *nix-систем как раз возможности обходить такие проблемы достаточно простыми способами. Мне приходилось работать под Linux на очень слабой машине с маленьким диском. Так что же на ней и ядро нельзя было по этому поводу пересобирать? Строго говоря, конечно, нельзя - просто негде было. Поэтому пересобрали на машине у коллеги и положили на мою :)

[Belansky]

Для себя вопрос "Как ставить: из пакетов или портов?" я решил однозначно - из портов.

[mar]

Belansky
я тоже. Это так, напоминание от разработчиков - в чем разница. :)

[Dungeon Keeper]

дададда порты рулят и фря рулит