Debian объявляет об официальной поддержке kFreeBSD

А User-Mode-kFreeBSD будет? Нужно для Неткита %)

>В netfilter'е, емнип, такие пакеты проходят как RELATED.

Как оказалось - не проходят. VPN-клиент может пинговать сервер во внутренней сети, может устанавливать TCP-подключения, но вот пакеты icmp mtu path dicovery от сервера не доходили. Это было на ядре 2.6.26 и iptables 1.4.2.

>В чём заключается целостность и самодостаточность и почему GNU недоделка? Из-за отсутствия собственного ядра?

Ядро есть, правда ещё довольно сильно недоработанное, а вот графической подсистемы нет вообще. Операционная система, которая не может обеспечить себя и юзерспейс базовыми подсистемами вроде графики или звука, ИМХО, называться операционной системой, и уж тем более иметь собственное название, не может.

>Бредом это является потому, что сейчас сложность проектов выросла. И глупо оценивать всю систему по объёму hello world и строчкам в скрипте configure - они предназначены не для простейших проектов, а для более менее сложных. Ну и никто не мешает использовать вместо этого тот же jam или boost.

Прекрасно. Сложность системы выросла - это ключевой момент. Unix - это набор простых утилит, взаимодействующих между собой через простые интерфейсы. Unix должен быть таким, чтобы любую его часть можно было легко понять, отладить, изменить или заменить полностью. Unix - это концепция минимализма и модульности, концепция простых интерфейсов. И если уж в GNU появляются такие программные монстры, для сборки которых применяются скрипты configure на сотни килобайт, а то и мегабайты, то в таком случае GNU - действительно не Unix.

>А вот на это только особо некомпетентный поведётся. uclibc была сделана для совсем embedded-систем, где не нужна арифметика с плавающей точкой, к примеру.

Могу более того сказать. Не могу представить ни одного системного вызова любой операционной системы, который бы использовал числа с плавающей запятой. Вся арифметика с плавающей запятой - это math.h, и она никоим образом с ядром операционной системы не связана. Пусть будет отдельная libmath или, как она изначально и называлась, libm.

>В результате при попытке построения такой системы с нуля придётся проделывать всё тот же путь. Да - может удастся не повторить ошибок вроде HAL. Но всё равно дело дойдёт до современного GNU - потому, что всё это реализовали не просто так, а по нужде и оптимизации работы с системой.

Нужды и оптимизации бывают разные. Кому-то они не подходят. Иначе бы не было и uclibc.

Моё мнение - libc должна быть интерфейсом к системным вызовам ядра, а всему остальному в ней не место. Функциям из stdio.h, strings.h, math.h в ней не место.

нет, плюс.
/жду pcbsd 8.0/

Не нужен. Я лучше PCBSD 8 подожду.

>Любая ФС и LVM даст больше.

Чего больше: неожиданностей или головняка?

1. Пофиг - лишь бы исходники были. Да и погоды это бзде не делает.

Кому как.

2. А в линуксе её типа нет?

Типа другое == сложное и неожиданное.

3. Оно раньше, чем в FreeBSD, в линуксе было.

Можно пруфлинк, а то я засомневался. В середине 1990-х Фри стояла на многих предприятиях и принимала входящие звонки по диалап-модему. Где тогда был Linux, сказать?

4. И? В линуксе нету?

5. В линуксе нету?

Mesh-сети в линуксе в зачаточном состоянии.

6. В линуксе нету?

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

7. И куда ZFS? В роутер?

В сервер.

8. Типа линукс меньше фрибзднишнего ядра собрать меньшим размером?

> uname -a
FreeBSD rio.fire 8.0-RC1 FreeBSD 8.0-RC1 #0: Tue Oct  6 20:46:08 VOLST 2009     root@rio.fire:/usr/obj/usr/src/sys/RIO  amd64
> du /boot/kernel/
 46M	/boot/kernel/
> ls -F /boot/kernel/ | wc -l
     560

— 557 модулей ядра. Из них загружено:

> kldstat | wc -l
      18

> чем их родная libc не устроила?

Тем, что с ней дофига всего не собирается

> Я так понимаю, что binary-compatibility с Linux + libc они все-равно не достигли

Зато достигли source-compatibility. Почти все что собралосьс linux/glibc, собирется и в freebsd/glibc, а вот про freebsd/libc такого сказать нельзя

>Как оказалось - не проходят. VPN-клиент может пинговать сервер во внутренней сети, может устанавливать TCP-подключения, но вот пакеты icmp mtu path dicovery от сервера не доходили. Это было на ядре 2.6.26 и iptables 1.4.2.

У меня — работает. Ядро из stable, iptables из testing. Нормальный openvpn без clamp-tcpmss-to-pmtu.

К тому же, емнип, PMTU discovery работает через icmp-destination-unreachable. Они обязаны проходить как RELATED согласно документации.

Если бы там был хоть малейший косяк, линух не смог бы работать фаерволом при ppp-доступе. Однако он вполне себе работает.

Скорее всего вы с sysctl перемудрили. Или RELATED забыли.

А вот насчет pf, видимо, никто из присутствующих не в курсе. А жаль :(

А вот и логотип для сабжа нашёл:

http://img79.imageshack.us/img79/4283/debiankfreebsd.png

(правда он из некошерного ксакепа)

Кстати, мне действительно интересно, как MTU discovery работает через pf. Неужели там нужно вручную разрешать icmp-destination-unreachable? keep state для них не работает? В netfilter'е, емнип, такие пакеты проходят как RELATED.

Разрешённые типы ICMP-пакетов указываешь и разрешаешь. Вот конфиг закрытого файервола, пропускающего только пинги:

#1) Macros:
# Разрешенные типы icmp сообщений:
#3 - unreach - Destination unreachable
#8 - echoreq - Echo request
allowed_icmp_types="{ echoreq, unreach }"
#---
#2) Tables:none
#---
#3) Options:
# тем, кто лезет туда, куда не нужно, - бить по рукам
set block-policy drop
# на интерфейсах петли пакеты не фильтровать
set skip on { lo }
#---
#4) Scrub:
# Нормализовать все входящие пакеты
scrub in all
#---
#5) Queueing:none
#---
#6) Translations: none
#---
#7) Filter Rules:
# Блокировать всё, что не разрешено
block all
# Разрешить определённый входящий и исходящий ICMP-трафик
pass inet proto icmp all icmp-type $allowed_icmp_types

> pfctl -nf /tmp/testpf.conf
[quote][[/code]](молчит, значит ошибок в правилах нет.)[br][/quote]Лишние строчки можно убрать и заменить тремя правилами:

# Нормализовать все входящие пакеты
scrub in all
# Блокировать всё, что не разрешено
block all
# Разрешить входящий и исходящий ICMP
pass inet proto icmp all icmp-type { echoreq, unreach }

Если PMTU discovery в pf можно разрешить только так, значит, в этом аспекте pf является stateless фаерволом.

Меж тем на дворе давно уже был двадцать первый век...

>Если PMTU discovery в pf можно разрешить только так, значит, в этом аспекте pf является stateless фаерволом.

"keep state" для правил давно уже используется по умолчанию, если не указано иного, так как на дворе уже 21 век...

>"keep state" для правил давно уже используется по умолчанию, если не указано иного, так как на дворе уже 21 век...

На дворе уже 21 век, а icmp-destination-unreachable так и не распознается keep-state. Можешь плакать.

В середине 1990-х Фри стояла на многих предприятиях и принимала входящие звонки по диалап-модему.

речь шла про pppoe, нэ? или у бсдшников телефоны через эзернет работают? но мне что-то подсказывает, что в середине 90-х юзался в основном SLIP (пруф - PPP родился в 1994 г.)

На дворе уже 21 век, а icmp-destination-unreachable так и не распознается keep-state. Можешь плакать.

Сам поплачь. Мне некогда:

% pfctl -sa | grep icmp
pass inet proto icmp all icmp-type echoreq keep state
pass inet proto icmp all icmp-type unreach keep state
icmp.first                   20s
icmp.error                   10s

>>И если уж в GNU появляются такие программные монстры, для сборки которых применяются скрипты configure на сотни килобайт....

скрипты появляются, когда ты хочешь, чтобы твоя программа собиралась и работала на любом юниксе и не очень, на котором её захотят запустить. Попробуй для начала родить makefile на несколько строчек, чтобы собрать что-то, отличное от hello world на десятке-другом систем, начиная от доса и заканчивая каким-нибудь vms'ом не говоря уже о всех видах юниксов и линуксов.

>>Любая ФС и LVM даст больше.

>Чего больше: неожиданностей или головняка?

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

>pass inet proto icmp all icmp-type unreach keep state

>Сам поплачь. Мне некогда:

Действительно, плакалЪ.

Ты написал stateless-правило, присобачил к нему ненужную keep state, да еще и гордишься этим!
Как говорят на башорке, «плакали все офисом».

Да, но если посмотреть на количество портов во FreeBSD, то их почти как пакетов в Debian. А то, что не собирается т.к. напрямую использует syscall-ы или какие-то Linux-специфичные вещи и так не соберется.

>Ты написал stateless-правило, присобачил к нему ненужную keep state, да еще и гордишься этим!

Я "keep state" не писал НИГДЕ. Разуй глазки.

я кстати что-то не понял

- а где во фряхе на ufs2 online дефрагментатор на отсутствие которого так жалуется iZEN.

- на какие такие отсутствующие барьеры в md (у 0/1/10 они есть 8-)) жалуется iZEN & Co b (не путать с dm - aka disk mapper, кстати там тоже они ебыли всегда практически для linear таргет 8-))

- что значит хочу вставить новый диск и что б сразу зеркало завелось? А с линуксом разве не так? сказал ядру через утилиту mdadm - "вот тот диск добавь в этот массив" и все полетело 8-) (что б на новый диск ядро автоматом начало зеркалить - за такое сразу убивать надо 8-), чай у нас тут не специализированная система хранения со "слотами" а ОС общего назначения)

- у LVM есть тоже свои плюсы (барьеры кстати уже есть в основной ветке), у меня есть сервер в котором диски в lvm-е менялись несколько раз - путем "вставил диск -> сделал его pv-> добавил в vg -> сказал старый диск убрать из vg -> подождал и вуаля -> данные уже на новом винте -> старый отключаешь и вытаскиваешь -> файловую систему расширяешь"

- про nat/iptables уже сказали - добавлю от себя что при всем удобстве синтаксиса pf зачем-то существуют трансляторы которые умеют строить под iptables/ipfw/pf, такие как firewall buider (я сам, например, чистый iptables, знаю но стараюсь пользоваться чем-нть типа ferm) недостатки есть и у pf и у iptables

- по поводу вопросов про nvidia/intel matrix raid/внезапно пропал звук и тд - вы сначала научитесь поддерживать хотя бы на уровне текущего линукса такие уст-ва и заимейте такую базу пользователей - потом поглядим на счет криков - думаю их хых не меньше будет.

- отвечая Quasar - он писал про pppoe, а ты dialup модемы вспоминал середины 90-х - линукс точно так же тогда поднимал обычное PPP c обычным mgetty - нехорошо подменять понятия 8-)

- экспорт винчестера по сети nbd, для более сложных случаев есть более другие инструменты - например drbd

>Я "keep state" не писал НИГДЕ. Разуй глазки.

stateless такой stateless :)
Вместо того, чтобы забыть вообще про icmp-destination-unreachable, потому что фаервол пропускает их как часть разрешенных соединений, фанаты stateless пишут для них отдельное правило.

Глумиться так глумиться!
Расскажи-ка мне, как ты пропускаешь через фаервол:
1. Пассивный FTP (фаервол на стороне сервера).
2. SIP
3. IRC
4. H.323
Все эти протоколы используют дополнительные соединения без жесткой привязки к портам. И отследить их можно только анализируя трафик. Я с удовольствием выслушаю, какие костыли для этого придумали под бзди.

Потом расскажи, как ты их натишь :D

Ну а потом, пожалуй, можно будет и про p2p вспомнить...

Лично я такого стратегического хода не понимаю.... из-за одного, по сути-то, файрвола? Сам пользую PF, для тех задач, что он выполняет - это просто монстр, а не файрвол... Но уж поверьте на слово... на практике основное его преимущество - никак не в офигенной структурированности его конфига... а в том, что этот файрвол является одновременно и шедулером пакетов (через ALTQ), и еще, имеет просто незаменимую вещь.. динамическое построение списков (я имею в виду tables, в родной для pf терминологии), например, из префиксов, полученных от определенного BGP пира... Кто бы вот мне сказал... я был бы очень благодарен за такую инфу... какой файрвол (ОС НЕ существенна, хоть виндоуз 98) еще так умеет?

Но вот по производительности... на фрибсд ни pf, ни berkeley ipf, по производительности с родным ipfw не потаскаются...

посему, целесообраность акцентирования такого внимания на аж целом файволе (и то портированном из другой системы, пусть даже тоже из BSD) запросто можно ставить под вопрос. pf портирован на фрю из оупенбсд... а теперь фрю подганяют под юзер-спейс линукса ради того, что в портируемой системе есть файрвол, портированный ранее еще откуда-то... А вообще это звучит )))) Кто со мной согласен?)))

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

P.S. зря вы, господа, спорите... что лучше.. линукс или фря... почитайте "Мастера и Маргариту"... там говорят "каждое ведомство должно заниматься своими делами"...

>Я с удовольствием выслушаю, какие костыли для этого придумали под бзди.

Читай pf.conf(5). Поумнеешь.

>на практике основное его преимущество - никак не в офигенной структурированности его конфига... а в том, что этот файрвол является одновременно и шедулером пакетов (через ALTQ)

Лично я не считаю то или иное разделение полномочий преимуществом недостатком. В линухе, например, netfilter решает три задачи:
1. Фильтрация.
2. NAT.
3. Различные модификации пакетов (изменение TOS, TTL, TCPMSS и т.п.)
а iproute2 занимается
1. Маршрутизацией
2. Шейпингом и приоретизацией.

В BSD же средства QoS интегрированы в фаерволы.
НУ И ЧТО?

>например, из префиксов, полученных от определенного BGP пира...

Лично для меня гораздо важнее списки, которые сам фаервол заполняет, выявляя досеров и портсканеров.

>pf портирован на фрю из оупенбсд... а теперь фрю подганяют под юзер-спейс линукса ради того, что в портируемой системе есть файрвол, портированный ранее еще откуда-то...

Угу. В доме, который построил Джек. pf из опенки и ZFS из солярки — вот главные аргументы Изи во славу фряхи! В только причем здесь фряха?

На вот, кушай: http://www.bastard.net/~kos/pf-voip.html

Зачем фаервол должен быть одновременно шедулером пакетов?

Зацепки из netfilter в сетевой стек у линукса есть, можно даже извратиться и на tc + ip состряпать фаервол - только надо ли?

надо наверное надут щеки как iZEN и послать читать доку по tc/ip 8-) хотя ответов там не будет (как собственно и в man pf.conf ответов на вопрос как занатить h323 8-))

>>Я с удовольствием выслушаю, какие костыли для этого придумали под бзди.
>Читай pf.conf(5). Поумнеешь.

И еще раз бугага. Ты и этого не знаешь :)

"ха ха ха"

8-( даже не смешно, а плакать хочется над тем что там написано.

>http://www.bastard.net/~kos/pf-voip.html

Продолжаешь люто, бешено доставлять!
>pass in quick on $int_if proto udp from $ipphone1 to any tag VOIP keep state

Пропустить все UDP без фильтрации.
Ну и зачем здесь фаервол? Чисто для ната и QoS?
В общем, слив не засчитан.

nnz, ты, видимо живешь в Раше, а я поживаю в Юкрейне, тут у нас есть такое аццкое понятие как "Уаикс" (точка обмена трафиком украинских операторов). Вот когда нужно шейпать клиентские траф РАЗДЕЛЬНО по направлениям, и нужно каким-то образом максимально быстро перестраивать списки этих направлений - вот тогда такая фича (о которой я говорил, про BGP пиров) и становится, мягко говоря, ОЧЕНЬ КСТАТИ.

Все то, о чем ты говорил в категории iptables, умеет и pf и ipfw, вот только, помимо этого они же еще и шейперы и квосеры (хотя тоже, для PF шейпер/квосер - ALTQ, а для IPFW - dummynet, родные pipes или netgraph), а маршрутизация - тут уже файрвол не при делах...

ты вот спросил "НУ И ЧТО", ну я отвечу - преимуществом фрюшного варианта считаю только то, что действия по шейпингу делаются на одном интерфейсе в обоих направлениях (и на ин и на аут) и меньшим количеством телодвижений. Насколько я помню, то iptables шейпают только на аут, и еще там пакеты нужно сначала "манглить метками на входном интерфейсе", а потом по этим меткам делать действия на ауте второго интерфейса... хотя это было два года назад... я тогда вообще не особо силен в этих делах был.... може и был другой вариант - но по другому не выходило. Вот и получается, что на одном действии - одно дополнительное движение, за счет чего дольше держится прерывание, требуемое для обработки пакета, вот отсюда разница в производительности.

В остальном - если другие "НУ И ЧТО" существуют - то я о них пока ничего не знаю...

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

Вобщем если выигрыши будут, то они будут совсем не от того, о чем говорится в сабже.

Хотя, не будь линукс силен в других вопросах, у него не было бы такой группы поддержки)))

вот отсюда и был вывод про "каждое ведомство должно заниматься своими делами"))))

>>pass in quick on $int_if proto udp from $ipphone1 to any tag VOIP keep state
>Пропустить все UDP без фильтрации.

Что значит "все"?!
О тегированном трафике ничего не слышал?

На, почитай: http://www.openbsd.org/faq/pf/ru/tagging.html

>а я поживаю в Юкрейне, тут у нас есть такое аццкое понятие как "Уаикс"

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

>Насколько я помню, то iptables шейпают только на аут

Ну, во-первых, айпистолы не шейпят. Они только классифицируют.
Во-вторых, IFB давно уже позволяет шейпить входящий трафик.

>и еще там пакеты нужно сначала "манглить метками на входном интерфейсе", а потом по этим меткам делать действия на ауте второго интерфейса...

На самом деле все гораздо проще. Нужно:
1. Классифицировать трафик. В простейших случаях это можно сделать через iproute2 (tc filter), в более сложных вариантах — через iptables (MARK, CONNMARK и CLASSIFY).
2. Прошейпить его. Этим занимается iproute2 (tc class и tc qdisc).

В том же PF/ALTQ, например, нужно
1. Указать, что трафик идет в такую-то очередь.
2. Описать саму очередь.

Имхо полная аналогия.

>IPFW, который даже per-user правила создавать умеет. Например, запретить одному из юзеров системы пингать хост А

Откройте для себя iptables owner match :)

>возможность прозрачно работать на bridged интерфейсах

и ebtables, да :)

>>>Любая ФС и LVM даст больше.

Можно с этого места поподробнее? Чего больше даст FAT + LVM? Или что там за ФС считается?

>>Чего больше: неожиданностей или головняка?

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

По делу сказать есть чего? Судя по переходам на личности и говорению за остальных - видимо нечего...

> хочу BSD/Linux, а не GNU/Linux
http://heirloom.sourceforge.net/

>Что значит "все"?!
>О тегированном трафике ничего не слышал?

Смотришь ты в конфиг pf, и видишь ты фигу :)
От того, что там тегируется весь UDP-трафик с определенного хоста, лишь слегка упрощается заворачивание трафика на QoS. В принципе тегирование для данной задачи не обязательно.
Ну а фильтрации там никакой нет.

Так что сначала сам сходи по предложенной тобой же ссылочке, потом обязательно почитай man pf.conf, и только потом снова пытайся учить жить взрослых дяденек.

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

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

Почитал тред и вспомнил одну вещь: есть 2 типа людей, одни понимают синтаксис iptables, другие - нет. А вот pf очень радует своей логичностью и вменяемым синтаксисом.

Отличная новость!

Интересно, ндо будет попробовать.

Вот кстати почитал тут 4 страницы срача и не заметил ни одного упоминания такой фичи ядра FreeBSD, как netgraph. Очень, имхо, полезная вещь, аналогов которой в ядре Linux даже близко нет.

> не заметил ни одного упоминания такой фичи ядра FreeBSD, как netgraph
А кого вообще волнуют какие-то фичи? Это ж ЛОР. Главное - срач устроить, да и тема располагающая.

>А вот и логотип для сабжа нашёл:

>http://img79.imageshack.us/img79/4283/debiankfreebsd.png

>(правда он из некошерного ксакепа)

Официальный логотип такой: http://io.debian.net/images/horned-logo.png

>Если бы там был хоть малейший косяк, линух не смог бы работать фаерволом при ppp-доступе. Однако он вполне себе работает.

Вполне работает. Пинги через туннель идут, они маленькие. А вот TCP-соединения рвутся, как только пакеты становятся достаточно большими. Хотя, проблема наблюдалась только с одним клиентом, остальные работали исправно. Просьба отключить фаерволл на стороне VPN-клиента была выполнена, но результата не дала.

>Скорее всего вы с sysctl перемудрили. Или RELATED забыли.

В sysctl включен форвардинг, остальное - по умолчанию из Debian. RELATED не забыл.

>Сам поплачь. Мне некогда:

Тебе некогда разобраться в вопросе. Воинствующее невежество.

Если разрешить только TCP подключение на 80 порт, будут ли обратно пропускаться ассоциированные с ним ICMP-пакеты? А если разрешить TCP-подключения на 21 порт, будут ли пропускаться соединения для передачи данных? А если разрешить подключение на 1723 порт TCP, будет ли разрешено прохождение GRE-пакетов для подключившихся клиентов?

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

>скрипты появляются, когда ты хочешь, чтобы твоя программа собиралась и работала на любом юниксе и не очень, на котором её захотят запустить. Попробуй для начала родить makefile на несколько строчек, чтобы собрать что-то, отличное от hello world на десятке-другом систем, начиная от доса и заканчивая каким-нибудь vms'ом не говоря уже о всех видах юниксов и линуксов.

pkgsrc и bmake не являются контрпримером?

>А вот TCP-соединения рвутся, как только пакеты становятся достаточно большими. Хотя, проблема наблюдалась только с одним клиентом, остальные работали исправно.

Скорее всего, проблема была в клиенте. Видимо, он по каким-то причинам не обрабатывал icmp-dest-unreach. Если это была винда, то поле для предположений довольно широкое :)

>>>>Любая ФС и LVM даст больше.

>Можно с этого места поподробнее? Чего больше даст FAT + LVM? Или что там за ФС считается?

FAT даже iZen за ФС не считает, шутник. Я говорю об ext3, reiserfs, xfs - они умеют ресайзиться и каждая хороша для своих задач. LVM в принципе вообще можно без ФС использовать, есть же СУБД, которые умеют располагать базы данных на raw-разделах. При чём, можно будет наращивать или уменьшать размер раздела офф-лайн, перемещать его с диска на диск он-лайн. И вот этого ZFS точно не может.

>Поищите количество сообщений на тему "загрузчик перестал загружать FreeBSD — честно, Windows не ставил", "ВНЕЗАПНО пропал звук, проблема точно не в засунутой новой HDMI-карте", "отвалился драйвер NVIDIA, xorg-server не переустанавливал", "GEOM mirror рассыпался на пустом месте и Intel Matrix Raid не виноват", "Система валится в кору на ZFS при диких нагрузках, процессор Celeron и 512МБ памяти — должно хватать". Таких сообщений просто нет или исчезающе мало на фоне криворукости/забывчивости пользователей FreeBSD. Для Linux — сплошь и рядом.

Ржу не магу убейся апстену. Если ты не найдешь таких сообщений, то это говорит лишь о том что фрю в большей своей части используют латентные виндузятники, а хватает их максимум на patty.exe и фрю в качестве шлюза. Все остальные кто действительно юзает бсд как десктоп эти проблемы решили для себя давным давно.

P.S. Против ври ни че не имею