>> А я ощущал обратное, когда использовал параллельно Debian и FreeBSD. В общем, давайте лучше сухими фактами оперировать, а не ощущениями...
> Сухие факты помимо уже сказанного - перловых модулей, например 2683 против 4995,
> это просто п* *ц.

Давайте перейдём к конкретике, чтобы понять почему нет этих модулей. Какого именно модуля вам не хватало в Debian?

Например, Debian любит исключать приложения с уязвимостями, на которые автор долго не реагирует. И правильно делает, IMHO.

> Даже игрушек нет, meandmyshadow, warsow, freeminer, openxcom
> - где всё это? Хорошо хоть meritous и chromium-bsu есть.

Из перечисленного знаю только openxcom. И то когда я его пробовал, он валился нафиг.

> И я повторяю: особенно странно такое видеть в третьем по популярности дистрибутиве,
> у которого пользователей, наверное, на пару порядков больше чем у фpи.

Чего странного? Легко подключаются репозитории и легко сверяются все необходимые цифровые подписи. В результате отсутствие какой-то несервеной и редкоиспользуемой вещи не доставляет неудобств даже при желании попробовать эту вещь (кроме некоторых исключений).

>> Можно ещё отдельно поговорить о работоспособности этих пакетов, но это уже совершенно другая тема.
> Сложно говорить о работоспособности того чего нeт.

Ну… Например, у вас valgrind нормально работает в сложных программах с sigwait во FreeBSD? Может поможете мне одну штуку от-debug-ить? На Debian-е всё замечательно, а вот во FreeBSD sigfault-ится нужная программа (которая, кстати, тоже включена в порты).

--46453-- WARNING: unhandled syscall: 429
--46453-- You may be able to write your own handler.
--46453-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--46453-- Nevertheless we consider this a bug.  Please report
--46453-- it at http://valgrind.org/support/bug_reports.html.
[...]
==46453== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==46453==  General Protection Fault
==46453==    at 0x20EAF2A: ??? (in /lib/libthr.so.3)
==46453==    by 0x3804A267: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==46453==    by 0x23686E2: ??? (in /lib/libc.so.7)
==46453==    by 0x236827F: fts_read (in /lib/libc.so.7)
[...]

Без valgrind конечно же segfault-ится в совершенно другом месте, кроме того fts_read-у точно передан правильный аргумент, а до этого никаких ошибок valgrind не сообщал (кроме указанной), то есть _данный_ segfault наведён самым valgrind-ом, либо он упустил где-то до этого ошибку работы с памятью (а-ля invalid write). Хотя зная, что он вылетает каждый раз на random-ной строке, если используется sigwait и вообще не вылетает, если sigwait не используется, то становится понятно, что всё дело лишь в:
--46453-- WARNING: unhandled syscall: 429
--46453-- You may be able to write your own handler.
--46453-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
который изчезает и появляется вместе с sigwait().

Почти весь день сегодня потратил на отладку проблем с segfault-ами на этой FreeBSD. Но из-за отсутствия вменяемых memory tracer-ов задача сильно усложняется. Ибо gdb не очень помогает, так как ошибки обычно наведённые откуда-то из другого места. Хотя в данном случае это не так раздражает, как отсутствие обычного inotify или какого-либо вменяемого аналога, но опять же, это уже отдельная песня. Если бы что-то было вменяемое, то вообще не пришлось бы через это всё проходить. И если вы захотите сослаться на libinotify-kqueue, который есть в портах, то он тоже segfault-ится при нормальных нагрузках, я уж не говорю про другие проблемы, а-ля https://github.com/dmatveev/libinotify-kqueue/issues/10 . Установил на виртуалку чистую систему чтобы сделать всего одну вещь, а наткнулся на полный глюкодром… И нет, я люблю FreeBSD. Просто я не считаю её лучше Debian, ровно как и Debian не считаю лучше FreeBSD. <captain>У них просто разные use case…</captain> Однако это я далеко ушёл от темы.

Если вернуться к теме количества пакетов, то просто объясните где ошибка в моей демонстрации (c «apt-cache»-ами), и тогда пойдёт конструктивный диалог.