Проект FreeBSD намерен сменить GCC на LLVM+Clang

>А /etc/master.passwd+/etc/passwd - не тоже самое "только вид в профиль"? :-)

Я думаю не стоит ему объяснять, почему сделано именно так, всё равно будет кричать, что в Linux всё криво.

Принципиально не то! passwd не имеет самостоятельной ценности, он *автоматически* генерится, путём усекновения некоторых полей, из master.passwd. Его хоть удаляй, всем пофиг. Одна команда, и он восстановлен. Рассинхронизация невозможна by design.

Что фрюха сама не идеал, это мне рассказывать не надо. Есть даже небольшое количесвто вещей, которые в некоторых линуксах сделаны лучше, чем аналоги во фрюхе. А эта твоя табличка при чём? Я давно в курсе, что юниксы друг от друга отличаются. Это в соляре killall в самом деле убивает ВСЕ процессы, вместо всех с заданным именем? А так да, собсно, именно составив умозрительно примерно такой вот перечень отличий, посчитав в какой колнке чаще встречаются реализации, которые мне кажутся прямее, логичнее, я и выбрал фрюху.

А ты попробуй! Мне интересно стало.

>Его хоть удаляй, всем пофиг.

Советую попробовать - забавно получится ;-). (Особенно при загрузке системы).

>Рассинхронизация невозможна by design.

$ vi /etc/master.passwd
[...]

Или

$ vi /etc/passwd
[...]

Не рассинхронизация? ;-)

Тут еще такое дело - у shadow "цели и задачи" немного другие - "man 5 shadow" поможет в понимании. (Tip: существенно большее количество полей для определения сроков действия и т.п.).

> Не рассинхронизация? ;-)

Нет. Потому, как vi /etc/master.passwd не достаточно. После этого необходимо сделать pwd_mkdb. Который сгенерит новый passwd на основе мастер-файла. Поэтому, vi /etc/master.passwd не Ъ, чоткие пацаны юзают vipw.

> Тут еще такое дело - у shadow "цели и задачи" немного другие - "man 5 shadow" поможет в понимании. (Tip: существенно большее количество полей для определения сроков действия и т.п.).

Э, а с чего ты взял, что в master.passwd полей меньше? Мне смутно помнится, что это в shadow их меньше, как раз. Нету же поля login class? А оно меня здорово выручило, когда я перетягивал аккаунты с линукса на фрюху. Не пришлось калечить всё, ограничился для импортированных акков отдельным классом.

>Нет. Потому, как vi /etc/master.passwd не достаточно.

Для рассинхронизации - достаточно.

>Поэтому, vi /etc/master.passwd не Ъ, чоткие пацаны юзают vipw.

Да вкурсе я! Просто некоторые НЕ ЗНАЮТ о наличии vipw. Вот и получается "рассинхронизация". (Сам таким был очень давно ;-).

$ man 5 passwd
[skip]
The master.passwd file is readable only by root, and consists of newline
separated records, one per user, containing ten colon (`:') separated
fields. These fields are as follows:

name User's login name.

password User's encrypted password.

uid User's id.

gid User's login group id.

class User's login class.

change Password change time.

expire Account expiration time.

gecos General information about the user.

home_dir User's home directory.

shell User's login shell.
[skip]

$ man 5 shadow
[skip]
shadow contains the encrypted password information for user's accounts
and optional the password aging information. Included is:

login name

encrypted password

days since Jan 1, 1970 that password was last changed

days before password may be changed

days after which password must be changed

days before password is to expire that user is warned

days after password expires that account is disabled

days since Jan 1, 1970 that account is disabled

a reserved field
[skip]

> Для рассинхронизации - достаточно.

Нет! Потому как отредактированный master.passwd системе будет пофик. Не, если именно passwd похачить, то да, возможно. До первого pwd_mkdb (прямо, или неявно после vipw).

> Просто некоторые НЕ ЗНАЮТ о наличии vipw.

Вах. Первое, что узнал. Ибо лениво было каждый раз базу паролей компиллить, после редактирования master.passwd. "Вот тебе и ещё одна выгода!" :)

>Нет! Потому как отредактированный master.passwd системе будет пофик.

Неправда! getpwent будет весело - пользователь вроде есть, а пароля к нему нет.

И? Поля class таки нету. Криво, тьху. Зачем гид и уид выносить в отдельный файл-то? Чтоб легче сломать было?

> Что фрюха сама не идеал, это мне рассказывать не надо. Есть даже небольшое количесвто вещей, которые в некоторых линуксах сделаны лучше, чем аналоги во фрюхе.

ну вот, значит плохо пытался переходить на linux

> А эта твоя табличка при чём? Я давно в курсе, что юниксы друг от друга отличаются

Как при чём? Проблемы возникли с shadow. Вот тебе мануал. Не понравилось - читай man 8 vipw

> Неправда! getpwent будет весело - пользователь вроде есть, а пароля к нему нет.

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

> ну вот, значит плохо пытался переходить на linux

Ну да. Не уверовал, не обратился в Истинную Веру.

> читай man 8 vipw

ЗАЧЕМ?!?! Что там читать-то? стандартный редактор, штатное конфигурирование парольного файла, выход. Переменная шелла EDITOR только мелочь, которая никак не влияет на суть.

>Человек просил _бинарный_ пакет.

Соберёт из порта -- получит бинарный пакет, ничем не хуже того, что есть на FTP-сервере 6-stable. :))

man master.passwd

The master.passwd file is readable only by root, and consists of newline separated records, one per user, containing ten colon (`:') separated
fields. These fields are as follows:
name User's login name.
password User's encrypted password.
uid User's id.
gid User's login group id.
class User's login class.
change Password change time.
expire Account expiration time.
gecos General information about the user.
home_dir User's home directory.
shell User's login shell.

The passwd file is generated from the master.passwd file by pwd_mkdb(8), has the class, change, and expire fields removed, and the password field replaced by a `*' character.

>То есть если я сидя на 6.2 захочу поставить один-единственный пакет, мне придётся обновить базу до 6.3

Нет. Это необязательно. Системное API в одной ветке стабильно.

>как минимум и обновить все пакеты до версий пактов из 6.3?

Возможно. Новый пакет поставится и будет ругань на установленные (зависимые) пакеты устаревших версий. Хотите, чтобы всё гарантированно работало, обновите и их. Пакеты можно ставить, используя URL и/или путь файловой системы к нужному тарболу.

> ЗАЧЕМ?!?! Что там читать-то? стандартный редактор, штатное конфигурирование парольного файла, выход

visudo тоже ничего особенного не делает, но зато заметен результат

>Пересборка пакетов без крайней необходимости - это красноглазие вообще, а не только красноглазие "бздунов". Сборкой пакета должен заниматься мэнтейнер.

Ничего он не должен.
Пакеты собираются из портов. Задача мантейнера предоставить необходимые файлы и патчи для порта и интегрировать его в дерево портов. А так же протестировать бесконфликтность сборки.
Собранный, установленный, но неработающий порт-пакет -- другая история.

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

А оно нужно?

>Вот в NetBSD есть стабильные ветки pkgsrc, а во FreeBSD стабильных веток портов нет. Поэтому именно "перманентные обновления с повышением версий".

И это правильно. Так и задумано. Потому что нельзя отличить патченный apache-1.3.41 от непатченного apache-1.3.41 без повышения его микроминорной версии, например, до такого вида: apache-1.3.41_1.

>Соберёт из порта -- получит бинарный пакет, ничем не хуже того, что есть на FTP-сервере 6-stable. :))

Вот она ИСТИНА-то! Хошь жить на относительно старой системе и ставиться пакетами (доводы приводил ранее - толщина канала и использование проца основные) - держи отдельную мафинку для сборки оных!!!

P.S.: И не надо больше гнать про бинарные обновления - НЕТ их во FreeBSD "искаропки".

P.P.S.: Так вобщем-то и делал пока не достало - две архитектуры (i386 и amd64), два типа процессоров (Intel и AMD). Итого: до 4-х разных сборок. Можно ограничиться 2-я, но тогда ассемблерные оптимизации криптографии и иже с ними пострадают...

>Бинарное обновление СИСТЕМЫ И ПАКЕТОВ для устранения известных уязвимостей во FreeBSD НЕВОЗМОЖНА.

А чем, по-вашему, занимаются freebsd-update и portupgrade -PP?

>А не могли бы вы мне пояснить какая такая страшная угроза навесает над сервером после установки xorg-minimal ?

Очень-очень старое и простое правило гласит: с увеличением числа программ количество уязвимостей растет.

Соответственно, чем меньше программ, тем меньше уязвимостей. Чем меньше их смотрит наружу, тем лучше.

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

> А оно нужно?

НУЖНО! Потому-как, например, притащили в порты в январе КРИВУУУУЩИЙ Xorg... И ВСЕ под него пропатчили. Тепереча вот попробуй собери на стабильной доселе машинке нормальное графическое окружение.

> И это правильно. Так и задумано. Потому что нельзя отличить патченный apache-1.3.41 от непатченного apache-1.3.41 без повышения его микроминорной версии, например, до такого вида: apache-1.3.41_1.

Э-э-э? Дядя смотрел в, например, http://www.openbsd.org/cgi-bin/cvsweb/ports/ ? Если нет, то рекомендую помотреть. НОРМАЛЬНЫЕ люди в портах к определенной версии системы имеют ветку с критическими исправлениями и ТОЛЬКО с ними. А обновления всяких там glib/gettext/iconv идут лесом, если они не несут в себе исправления критических ошибок.

А нумерация версии пакета при этом аналогично изменяется. Тут ничего нового не придумаешь...

>Можно ограничиться 2-я, но тогда ассемблерные оптимизации криптографии и иже с ними пострадают...

А для Linux разве не так?

>А чем, по-вашему, занимаются freebsd-update и portupgrade -PP?

Профонацией возможности. См. ветку выше. Кратко для забывчивых:

1) freebsd-update - хорошо обновляет базовую систему в пределах патчбранч.

2) portupgrade -PP - не УМЕЕТ ставить исправленные пакеты для патчбранч потому-как их НИКТО не собирает.

>>Можно ограничиться 2-я, но тогда ассемблерные оптимизации криптографии и иже с ними пострадают...

>А для Linux разве не так?

Также. Только там бинарные сборки УЖЕ ЕСТЬ. И не надо самому пакеты под 4-е варианта собирать (i386/p4, i386/k8, amd64/nocona, amd64/athlon64).

>НУЖНО! Потому-как, например, притащили в порты в январе КРИВУУУУЩИЙ Xorg... И ВСЕ под него пропатчили. Тепереча вот попробуй собери на стабильной доселе машинке нормальное графическое окружение.

Есть замороженные ветки деревьев коллекции портов на определённый момент времени. Из хранилища CVSup можно забрать замороженное дерево.

Дальше начинается для вас самое интересное -- берёте каталоги с патчами и сценариями сборки интересующих вас портов из новейшего снапшота коллекции или из предыдущего среза, редактируете Makefile'и, проверяете бесконфликтность сборки, собираете собственные пакеты и пользуетесь ими.

Главное ведь, никто не запрещает иметь собственное (урезанное или дополненное) дерево портов!

- Поручик, вы пьяны, вы омерзительно пьяны! - Ик! Зато у Вас, Наташа, ноги кривые. А я завтра трезвый буду.

Если фришники найдут, кто будет держать репозитории собранных пакетов, мэйнтэйнить их, то основные претензии уйдут. Но кривизна линукса никуда не денется! ;)

>portupgrade -PP - не УМЕЕТ ставить исправленные пакеты для патчбранч потому-как их НИКТО не собирает.

Ну почему же у меня оно обновляет бинарными пакетами установленное ПО на FreeBSD 7.1-RELEASE-p4? Наверно потому, что я засинхронизировал дерево портов?

>Истинная причина исключительно в том, что система была приведена в ужасающее состояние. По сути, из федорки сделали слаку, сохранив все недостатки федорки и добавив слаковский бардак. Ну, блин, поставил бы я тот юм, и что? Вся система уже была напичкана самосбором, как бы юм с ним разбирался-то?

С этого и надо было начинать: вся система была напичкана самосбором, а не yum было лень искать.

[skip]

> Главное ведь, никто не запрещает иметь собственное (урезанное или дополненное) дерево портов!

ЖЕСТЬ!..

Чем-то напоминает:
--------------------------------
Идет женщина по лесу. Лето, жара под 30. Видит - стоит на поляне мужчина в полном водолазном облачении (костюм, ласты, маска, акваланг - все как положено) и косит траву.

- Что вы делаете? спрашивает женщина
- Кошу траву.
- Но почему в таком виде?
- Я член клуба любителей преодолевать трудности..
- Понятно. Ответила женщина и пошла дальше..

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

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

Как достанет - добро пожпловать в любой мир пакетных дистрибутивов или хоть систем с отдельными ветками портов для стабильной версии.

(Меня достало - перешел).

>Также. Только там бинарные сборки УЖЕ ЕСТЬ.

По сравнению с Фри на одну-две минорных версии древнее...

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

>Если фришники найдут, кто будет держать репозитории собранных пакетов, мэйнтэйнить их, то основные претензии уйдут.

КАНЕШНА. Только делать этого НИКТО не будет. Вот накатили кривой Xorg и похрену было, что оно нерабочее. А тут еще всякие там фуфелфоксы еще и под старые версии Xorg-ов им подавай! ;-)

>Но кривизна линукса никуда не денется! ;)

Э? 8-)

Оно не более кривое, чем фря. Если НОРМАЛЬНЫЙ дистриб взять.

> С этого и надо было начинать: вся система была напичкана самосбором, а не yum было лень искать.

Для меня важнее было, что юм из системы выпилен был. Это запомнилось и поразило. И именно поэтому это как пример привёл. Самосбор - проявление отсутствия юма.

Но срач получился (почти)эпический :)

>По сравнению с Фри на одну-две минорных версии древнее...

Ну и что? От сервера что надо? Чтоб пальцы? Или чтоб продолжало стабильно работать?

> Только делать этого НИКТО не будет.

Как знать, как знать. Прогресс, однако, имеется. По сравнению с тем, как было раньше :)

> Оно не более кривое, чем фря. Если НОРМАЛЬНЫЙ дистриб взять.

Ага. Вот только какой именно из них НОРМАЛЬНЫЙ, мнений значительно (over 9000, аднака :) ) больше одного.

>> Только делать этого НИКТО не будет.

>Как знать, как знать. Прогресс, однако, имеется. По сравнению с тем, как было раньше :)

Прогресс? Дак как jkh к яблокам ушел (который и "порагам" за кривой базовый пакет мог...), так все только хуже становится.

> Ага. Вот только какой именно из них НОРМАЛЬНЫЙ, мнений значительно (over 9000, аднака :) ) больше одного.

Дык и ремюзе есть. Для ленивых. И попробовать не напрягает вобщем-то...

Я вот так думаю (Сервера прежде всего):

1) CentOS/RHEL/FC - для скептиков. Все "как по книжке".

2) Mandriva/AltLinux/SLES/OpenSUSE - для фанатов и "маньяков". :-)

3) Debian/Stable - для ленивых (после установки нового stable долго не предвидится никаких чудес).

4) Debian/testing - для любителей немного поэксперементировать.

5) Crux/Arch - для любителей делать все "под себя проточенное".

6) Slackware - ничего не скажу. Не "вкурил".

7) Gentoo - "Поновее подавай!" "А ebuild-ы будут?" ;-)

>1) CentOS/RHEL/FC - для скептиков. Все "как по книжке".

А оно вообще рабочее или хронически тестовое?

>2) Mandriva/AltLinux/SLES/OpenSUSE - для фанатов и "маньяков". :-)

Десктоп. Для Windows-свитчеров.

>3) Debian/Stable - для ленивых (после установки нового stable долго не предвидится никаких чудес).

Зато как жахнет -- мало не покажется. :))

>4) Debian/testing - для любителей немного поэксперементировать.

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

>5) Crux/Arch - для любителей делать все "под себя проточенное".

Для красноглазиков самое то. Поддерживаю.

>7) Gentoo - "Поновее подавай!" "А ebuild-ы будут?" ;-)

В последнее время скорость портирования новья удручает. Становится как в Debian testing.

>>1) CentOS/RHEL/FC - для скептиков. Все "как по книжке".

>А оно вообще рабочее или хронически тестовое?

CentOS-то с RHEL? ОЧЕНЬ даже рабочее. Только как-бы это сказать... Меня первые часа два после установки тошнит сильно пока всякую нахрен-не-нужную-срань оттедова не поудаляю.

>>2) Mandriva/AltLinux/SLES/OpenSUSE - для фанатов и "маньяков". :-)

>Десктоп. Для Windows-свитчеров.

Alt - не дусктоп! Там и сервер есть. Для фанов и маньяков правда только. Что-то в этом есть, только НАСТОЛЬКО своеобразное...

>>3) Debian/Stable - для ленивых (после установки нового stable долго не предвидится никаких чудес).

>Зато как жахнет -- мало не покажется. :))

Было как-то такое дело... Давно только очень. Расслабляет, знаете-ли...

>>Человек просил _бинарный_ пакет.

>Соберёт из порта -- получит бинарный пакет, ничем не хуже того, что есть на FTP-сервере 6-stable. :))

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

>>То есть если я сидя на 6.2 захочу поставить один-единственный пакет, мне придётся обновить базу до 6.3

>Нет. Это необязательно. Системное API в одной ветке стабильно.

>>как минимум и обновить все пакеты до версий пактов из 6.3?

>Возможно.

Вы сами себя послушайте: "Обновлять не обязательно, но возможно придётся." То есть вы кагбэ пытаетесь обмануть и меня и самого себя?

>Новый пакет поставится и будет ругань на установленные (зависимые) пакеты устаревших версий. Хотите, чтобы всё гарантированно работало, обновите и их. Пакеты можно ставить, используя URL и/или путь файловой системы к нужному тарболу.

Вот именно. Обновите всё, чтобы просто поставить ещё один пакет.

> собрать пакет новой версии, не снеся старый, не получится.

Получится.

>То есть если я сидя на 6.2 захочу поставить один-единственный пакет, мне придётся обновить базу до 6.3
>>Нет. Это необязательно. Системное API в одной ветке стабильно.

>как минимум и обновить все пакеты до версий пактов из 6.3?
>>Возможно.

>Вы сами себя послушайте: "Обновлять не обязательно, но возможно придётся." То есть вы кагбэ пытаетесь обмануть и меня и самого себя?

Я пытаюсь вам объяснить независимость системы от портов.

> Только если в системе уже стоит этот пакет, но более старой версии, то просто собрать пакет новой версии, не снеся старый, не получится.

CHROOT=/var/build
kernconf=MYKERNEL

mkdir -p $CHROOT
cd /usr/src
make DESTDIR=$CHROOT installworld
cp /boot/device.hints $CHROOT/boot
make DESTDIR=$CHROOT installkernel KERNCONF=$kernconf
cd etc
make DESTDIR=$CHROOT distribution
cp /etc/resolv.conf $CHROOT/etc
cp /etc/make.conf $CHROOT/etc
cp /etc/src.conf $CHROOT/etc
cd ..
mkdir -p $CHROOT/usr/src
find . -depth -xdev -print|cpio -pdm $CHROOT/usr/src
cd /usr/ports
mkdir -p $CHROOT/usr/ports
find . -depth -xdev -print|cpio -pdm $CHROOT/usr/ports
chroot $CHROOT

> Вот именно. Обновите всё, чтобы просто поставить ещё один пакет.

А чего ты хотел-то? Это ж бубльгум^w опенсурс! Депенденсез хелл. Каждый разраб из принципа задействует всегда наиновейшие библиотечки, ни на йоту не заморачиваясь похеренной вертикальной совместимостью. Собор не базар, едрыть!

>Если фришники найдут, кто будет держать репозитории собранных пакетов, мэйнтэйнить их, то основные претензии уйдут.

Если да кабы... Вот когда будет, тогда и будем говорить. Фришников не дождёшься, когда они сами сделают. Дебианщики уже взялись портировать систему на их ядро. Debian - это Linux, лучший чем Linux и будет FreeBSD, лучший чем FreeBSD.

>Но кривизна линукса никуда не денется! ;)

Но кривизна портов фри тоже никуда не денется.

Или примеры кривизны линукса исчерпываются только файлами passwd и shadows?

>>Новый пакет поставится и будет ругань на установленные (зависимые) пакеты устаревших версий. Хотите, чтобы всё гарантированно работало, обновите и их. Пакеты можно ставить, используя URL и/или путь файловой системы к нужному тарболу.

>Вот именно. Обновите всё, чтобы просто поставить ещё один пакет.

В каком месте я произнёс слово "всё" и подумайте, почему.

>Но кривизна портов фри тоже никуда не денется.

В чём "кривизна портов" выражается, объясните мне, несчастному, измученному нарзаном. :))