Linux и FreeBSD: сравнение (Страница 1 из 8)

теперь по статье:

нормальное такое начала объективного обзора...

а также кучу всякого хлама на всякий случай. список загруженных модулей в debian'овом ядре у меня не вмещается в экран.

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

нет там STREAMS, и никогда не было. в BSD - тем более.

ой, а мужики-то и не знали!

>>На большинстве же современных платформ лучше воспользоваться Linux.
>нормальное такое начала объективного обзора...

Языком трепать на форумах все горазды. Платформ Linux поддерживает больше. Чтобы не пришлось постоянно скакать с системы на систему лучше выбирать ту, которая поддерживает больше платформ. Можно выбрать по этому критерию NetBSD, но я думаю ни для кого не секрет, что функциональность у неё гораздо ниже.

>>Linux при загрузке автоматически определяет всё доступное оборудование и загружает необходимые драйверы-модули ядра.
>а также кучу всякого хлама на всякий случай. список загруженных модулей в debian'овом ядре у меня не вмещается в экран.

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

>Возможно это справедливо и для Linux.
>возможно, завтра луна причалит к земле, и по трапу спустятся три роты кавайный инопланетяшек. это обзор или болтовня на скамейке?

Ладно, слово "возможно" там лишнее. Ну а сам-то ты пришёл предложение дельное внести или поболтать на скамейке?

>>В Linux была реализация модульной сетевой подсистемы STREAMS
>нет там STREAMS, и никогда не было. в BSD - тем более.

Ну а я вот нашёл упоминание, что проприетарный набор модулей ядра для поддержки STREAMS for Linux был. Посмотрите сами: google.com/search?q=STREAMS+for+Linux&ie=utf-8&oe=utf-8&aq=t&rls=org.debian:ru:unofficial&client=iceweasel-a

>>Поддержка Unicode во FreeBSD появилась только начиная с версии 7.0
>Откровение... Выходит, я зря прописывал локаль ru_RU.UTF-8 для Xfce 4.2 на FreeBSD 6.1 — оно не должно было работать. big_smile
И прописывал в fstab перекодировку в 8-битную таблицу. Так? Да, GNOME перешёл на Unicode раньше FreeBSD. XFCE, ЕМНИП, использует гномовские библиотеки.

>Во FreeBSD появилась возможность при компиляции нового ядра указывать про поддержку 16 таблиц маршрутизации.
>opennet.ru/opennews/art.shtml?num=15811

О чём я и сказал, появилось только в версии 7.0. Читать разучился? Да, ещё оно бэкпортировано в 6.3.

Пока что конструктивных предложений по статье не услышал.

Во FreeBSD используется не та OSS, которая понимается в Linux. В самой системе совершенно другие драйверы. OSS идёт в виде отдельного порта: ports/audio/oss

ALSA реализована в виде порта: ports/audio/linux-alsa-lib для линуксулатора.

Ну ещё и на своих собственных
Которые, правда, тоже к гному никакого отношения не имеют

Ага.
% rm -rf /usr/local/* && rm -rf /var/db/pkg/* && rm -rf /var/db/ports/*

csup и make применяются и для обновления системы, и для сборки/обновлении ПО из портов единообразно.

Ага.
% rm -rf /usr/local/* && rm -rf /var/db/pkg/* && rm -rf /var/db/ports/*

Примерно раз в полгода, когда появляется необходимость очистить [s]систему[/s] каталог программ от ненужного хлама.

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

Отредактировано iZEN (2008-11-24 22:45:25)

2 iZen
>Не всё так радужно — среди файлов /usr/src можно найти исходники с копирайтом AT&T.
Полагаю Вы знаете что такое websvn, webcvs и прочие. Пруфлинк или не было.

>По мировому соглашению от января 1994 года
Пруфлинк на файлы FreeBSD с лицензией AT&T.

>Так ли часто встречается задача "снести все программы" на практике?
>Примерно раз в полгода, когда появляется необходимость очистить [s]систему[/s] каталог программ от ненужного хлама.
Это по старой памяти о Windows, где всё нужно переставлять раз в пол-года? Надёжно работающей системе с хорошим пакетным менеджером такой функционал не нужен.

>Кому как. Можно вообще ничего не обновлять годами и пользоваться тем, что изобретено в прошлом веке...
Можно и не обновляться. Хорошее правило сисадмина: "работает - не трогай". Единственное исключение - дырки в сервисах всё же надо закрывать. Пример - работающий Интернет-сервер, например почтовый, например под CentOS или Debian. Зачем его обновлять, если он успешно справляется со своими функциями, а дырки оперативно закрываются?

>Архитектура arm недавно включена в разработку под FreeBSD:
>http://www.freebsd.org/platforms/arm.html
К сожалению во FreeBSD так почти со всем: только-только реализовано или начинает реализовываться. Это отставание от Linux похоже будет длиться бесконечно.

>Общая идея такова: не перебирать kldload'ом все доступные для подгрузки модули звуковух, а загрузить их все и определить, какой из них подключился, затем прописать в /boot/loader.conf этот модуль в автозагрузку.
Суть от этого не меняется. Кроме того, в памяти останутся даже те модули, которые своего оборудования не нашли. Их потом вручную нужно выгружать или перезагрузить компьютер.

Вообще очень многие представления о правильности поведения FreeBSD меняются когда приходится оперировать большим количеством машин: десятками Интернет-серверов, которые нужно оперативно обновлять, и сотнями рабочих станций с крайне отличающимся оборудованием. Сервера нужно постоянно обновлять - каждый день или даже чаще. В случае FreeBSD без танцев с бубном не обойтись, тут тебе и отдельная машинка для сборки пакетов, и кросскомпиляция. С рабочими станциями ситуация трудна в части поддержки оборудования и с теми же пакетами. Во FreeBSD, всё-таки надо это признать, они без пересборки во многих случаях к использованию непригодны. Кроме того, как быть с загрузкой BSD по сети? Под каждого клиента собирать своё ядро с поддержкой необходимого оборудования? Или воспользоваться Linux, который загрузится в минимальной конфигурации, а потом подтянет остальные модули для поддержки нужного оборудования с уже смонтированной NFS-шары?

>find находит на раз-два.
Верю. У меня под рукой нет исходников FreeBSD, поэтому прошу пруфлинк на webcvs.

>Во FreeBSD стандартными методами (системными утилитами pkg_*) трудно (хотя и можно) отследить оторванные от основного графа зависимостей болтающиеся сами по себе и больше никому ненужные библиотеки.

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

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

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

>Если я, например, перешёл на KDE/Qt, а Xfce/Gtk и библиотеки GNOME мне по большому счёту не нужны, то вычищением их зависимостей утилитами pkg_delete/pkg_info мне не улыбается. И что, разве в Debian не так?

Не так, я уже описал как в Debian. Вырвитесь уже наконец за пределы FreeBSD и посмотрите на Debian, хотя бы. Только смотрите долго и пристально, в течение месяцев двух хотя-бы и с постоянным чтением документации.

>Да, вообще-то, во FreeBSD дырки в системе чинятся отдельно от дырок в приложениях. То есть для закрытия дырки в системе выпускается патч за номером и после пересборки система получает новую ревизию, например, FreeBSD 6.3-RELEASE-p4.

Поэтому я считаю достоинством Debian то, что не происходит искусственного деления ядра от программ. Ядро обновляется абсолютно так же, как и программы.

>Дырки в приложениях чинятся разработчиками этих приложений, если это действительно не на совести мантейнера. Разделение труда, так сказать, и ответственности. В Debian такого, наверно нет, — разработчики дистрибутива починяют всё на свете, поэтому и включение новых версий программ в дистрибутив движется так медленно.

То же самое происходит и в Debian. Мэнтейнеры связываются с разработчиком и совместно патчат багу. Если разработчик забросил проект - мэнтейнер патчит багу самостоятельно если это ветка stable или просто выбрасывает пакет если это testing, готовящийся стать новым stable.

А медленно всё движется только в ветке stable. Debian по-настоящему считается stable, когда нет ни одного не закрытого багрепорта. В ветках testing и unstable всё движется гораздо быстрее, но там и требования мягче.

Отредактировано morbo (2008-11-25 08:40:07)

Вообще-то, у меня - 1251
Но проверю - недавно ковыряли настройки, м.б. что и слетело.

Так вот и предлагается не спорить, а обсуждать.
И вообще этот форум существует для обсуждения вопросов, интересных участниками.
А любая конкретная статья, будь она хоть за авторством Господа Бога, лишь повод для такого обсуждения.

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

И вот тут уже начинаются претензии к Вашей статье. Собственно, одна и главная претензия: Вы всё смешали в одну кучу. И маршрутизацию, и управление пакетами, и поддержку звуковых карт, и многоплатформенность, и особенности взаимодействия ядра и модулей.
Так что давайте для начала определимся, что нас интересует - серверный сегмент или пользовательский, или вообще встраиваемые системы (раз уж были помянуты ARM'ы).
Если серверный - поддержка звуковых карт не должна волновать нас в принципе. Что-то не видел я серверов с мощными современными акустическими системами И пакетный менеджмент интересует нас в одном аспекте - обновлений безопасности.
Если речь идёт о пользовательских машинах - нас перестают интересовать вопросы маршрутизации, многоплатформенность etc., а пакетный менеджмент становится в первую очередь средством для обновления пользовательских программ.
А со встраиваемыми системами вообще отдельная песня. Если мы занимаемся их разработкой - это одно дело. Если же мы просто их пользователи, нас интересует... да ничего нас не интересует, даже вопрос о том, какая ОС стоит на мобильнике и есть ли там ОС вообще (кстати, отсутствие ОС в этом случае мне представляется предпочтительным )

Так что вот давайте посомтрим по пунктам. Чтобы не писать многокилометровые посты - каждый по отдельности.

Что, GENERIC-ядро во многих случаях непригодно?

GENERIC ядро, как правило, достаточно большему числу населения.

Установка FreeBSD также штатно возможна с bootonly-cd, если вас это интересует. Так же подтягивает с NFS-шары или FTP-архива нужные бинарные чанки для развёртывания системы на целевой машине. Обновление бинарными модулями осуществляется так же.

Специально для верующих:

> grep 'AT&T' -r /usr/src
...
/usr/src/usr.bin/rpcinfo/rpcinfo.8:.\" Copyright 1989 AT&T
/usr/src/usr.bin/rpcgen/rpc_parse.h:/*    Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T    */
/usr/src/usr.bin/rpcgen/rpc_parse.h:/*    THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T    */
/usr/src/usr.bin/rpcgen/rpc_parse.h:* constituting, or derived under license from AT&T's UNIX(r) System V.
/usr/src/usr.bin/rpcgen/rpc_parse.h:*    (c) 1983,1984,1985,1986,1987,1988,1989  AT&T.
/usr/src/usr.bin/rpcgen/rpc_scan.h:/*    Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T    */
/usr/src/usr.bin/rpcgen/rpc_scan.h:/*    THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T    */
/usr/src/usr.bin/rpcgen/rpc_scan.h:* constituting, or derived under license from AT&T's UNIX(r) System V.
/usr/src/usr.bin/rpcgen/rpc_scan.h:*    (c) 1983,1984,1985,1986,1987,1988,1989  AT&T.
/usr/src/usr.bin/rpcgen/rpc_util.h:/*    Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T    */
/usr/src/usr.bin/rpcgen/rpc_util.h:/*    THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T    */
/usr/src/usr.bin/rpcgen/rpc_util.h:* constituting, or derived under license from AT&T's UNIX(r) System V.
/usr/src/usr.bin/rpcgen/rpc_util.h:*    (c) 1983,1984,1985,1986,1987,1988,1989  AT&T.
...
/usr/src/lib/libcompat/regexp/COPYRIGHT:these files contain AT&T proprietary source code.
/usr/src/lib/libc/stdlib/tdelete.c: * the AT&T man page says.
/usr/src/lib/libc/stdlib/tfind.c: * the AT&T man page says.
/usr/src/lib/libc/stdlib/tsearch.c: * the AT&T man page says.
/usr/src/lib/libc/stdlib/twalk.c: * the AT&T man page says.
/usr/src/lib/libc/rpc/rpc.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/getnetconfig.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/getnetpath.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc.5:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_clnt_auth.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_clnt_calls.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_clnt_create.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_svc_calls.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_svc_create.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_svc_err.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_svc_reg.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpc_xdr.3:.\" Copyright 1989 AT&T
/usr/src/lib/libc/rpc/rpcbind.3:.\" Copyright 1989 AT&T
...

/usr/src/usr.bin/rpcgen/rpc_util.h:

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

В Debian много мелких пакетиков именно "на каждый чих", когда из одного программного продукта мантейнеры-дистрибуторы делают множество бинарных пакетиков с разными типами связей (жёсткие, мягкие, рекомендуемые и т.д.), от которых глаза разбегаются и не всегда знаешь, что нужно точно установить, чтобы оно работало. Так, в Debian поделена JRE на три или более пакетов, после установки у людей почему-то не вводятся русские символы в графических java-приложениях — приходится доустанавливать языковой пакет. В то время как в нормальных системах всё работает "из коробки" — JRE ставится одним пакетом (вместе с плагином для Web-браузера для запуска апплетов в нём) и таких казусов не возникает.

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

И FreeBSD обновляется так же, как и программы. Что не так?

До сих пор в Debian нет [s]порта[/s] бинарного пакета Eclipse 3.4.1 не то что в стабильной или в тестовой ветке, но даже в экспериментальной. И никому до этого нет дела.

Да в Debian и Eclipse 3.3.x не наблюдается:
packages.debian.org/search?keywords=eclipse&searchon=names&suite=all&section=all
Неожиданно как-то.

Во FreeBSD, хоть эта система и не поддерживается официально коммунити Eclipse.org, но всё-таки есть порт Eclipse 3.4.1 (ports/java/eclipse-devel), который собирается из исходников с весьма нетривиальными патчами порта, тем не менее не требует линуксулатора для своей работы. Eclipse 3.3.2 "Europa-Winter" (ports/java/eclipse) стабилен с мая месяца.

Отредактировано iZEN (2008-11-25 10:38:32)

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

> uname -rsm
FreeBSD 7.1-PRERELEASE i386
> pkg_info | grep firefox
firefox-3.0.4,1     Web browser based on the browser portion of Mozilla

Вы опять в Debian какой-то пакетик автоопределения кодировки забыли/не доустановили?

Отредактировано iZEN (2008-11-25 11:09:54)