> я не про опции. wine на amd64 был(и вроде сейчас тоже) помечен
> как сломанный.
> В той же gentoo wine прекрасно работал на x86_64(просто собранный с -m32
> и через 32битные библиотеки). Т.е. либо мантейнеру было лень, либо в
> freebsd имелись серьёзные проблемы с запуском 32битных приложений с 64битным ядром.

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

> Попадался еще софт, который нормально работал на 32битной фре/линуксе и 64битном линуксе,
> но на 64битной фре спорадически крэшился. Именно за это люди платят
> покупая rhel/sles
> (пусть даже ценой более древних версий).

ну и плюс к этому ограничиваются софтом который им предлагается либо лешаются поддержки.

>> Софт собранный более новым или более старым компилятором тоже может неработать и
>> это нормально. У много софта есть тесты используйье их в крайнем
>> случае напишите свои.
> вы предлагаете взвалить на себя работу мантейнера.

Мантейнер вам ничего не дложен и не обязан, желаете что бы за вас все тестировалии - платите денюжку
В конечном итоге админ вы или кто?

>>> Некоторые разработчики(например, любимый некоторыми proftpd) security fix'ы закрывают
>>> выходом новой мажорной версии(да еще с релиз-кандидатом).
>> Вот поэтому во фре другой.
> кто другой? proftpd? в дебиане proftpd заморожен в рамках релиза.

а фиксы накатывают из новых мажорных версий?

>>> Это если бы вам предложили для закрытия имеющейся проблемы с RELEASE/STABLE переехать
>>> на CURRENT.
>> Вспомните как за 2-е суток ссш дважды ломанули. А что нельзя было
>> сразу второй патч выложить ?
> ну да, факап debian security team. freebsd от этого не защищена(в любом
> случае держать хорошего security-спеца как Brad Spengler в команде стоит хороших
> денег и ). если для вас столь критично, используйте rhel/sles.

а как от этого защищены rhel/sles?