/mnt/storage/mp3/Manowar

... и се сетя че всъщност не съм имал предвид "Manowar" като последна директория, а "rammstein". Единия начин да оправя това е като набия 7 backspace-а и да изтрия всяка буква поотделно, докато стигна до наклонената черта. Ами ако се сетя че "rammstein" не е в "mp3", а в "/mnt/storage/Music"? Тогава чаткането по backspace става още повече.
В csh това става елементарно с CTRL-W - комбинацията изтрива всичко от командния ред до предната наклонена черта.
Така

/mnt/storage/mp3/Manowar

става

/mnt/storage/mp3/

с един CTRL-W. Следващия CTRL-W ще махне "mp3/", следващия ще махне "storage/" и т.н.
Гугъл върна един резултат на това търсене - тук в Shallow Thoughts.
На кракто решението е следното:
Това отива в ~/.inputrc:

set bind-tty-special-chars Off

А това отива в ~/.bash_profile:

bind '\C-w:backward-kill-word'

Шела се рестартира (logout -> login) и трябва да работи.
Обяснение на дълго защо се случва това - в горния линк.

• RRDtool - има страхотни възможности за представяне на числова информация. За примерни графики вижте галерията им.
• ping - резултата от изпълнението на ping съдържа всичко необходимо за изграждане на статистиката ни - Round trip time и Packet loss
• Perl - или друг удобен ви език. Трябва ви за парсване на изхода от ping
• crontab - искаме статистиката да се събира през определен интервал от време

Системата може да бъде разделена на две части: част за събиране на статистика и част за графично представяне на данните.
Събиране на статистика
На всеки 5 минути ще се пуска ping до няколко избрани хоста в различни зони на пиъринга. Естествено върнатите резултати ще са субективни, защото зависят от параметрите на отсрещната точка. Все пак цялото задание "качество на нета" е субективно, така че да продължаваме Избрал съм единия хост да бъде шлюза на доставчика ми, втория хост да бъде dir.bg (тест на bg пиъринга) и третия хост да бъде ivanatora.info (за тест на международната свързаност).
Логът се изгражда от следния скрипт:
/home/ivanatora/perl_razni/ping_stats.pl

Малко изпреварвам времето, защото още не сме създали RRD базите. Каква е идеята на RRD? Round Robin Database е способ за запазване на постоянно изменяща се информация във времето, като всяка промяна се регистрира в цикличен буфер. Ако имаме един буфер със 12 слота и ъпдейтваме базата през 5 минути, във всеки момент ще имаме данните от предния час. Какво става с по-старите данни - губят ли се? Да. Ако ни трябват ще направим още един буфер, който ще се ъпдейтва на всяко цялостно извъртане на часовия буфер - ще взима средната стойност на всички измервания и ще го записва в един негов слот. Така ако този буфер има 24 слота ще имаме статистика на средната часова стойност на измерванията. Може да имате колкото си искате вторични буфери и всички се съхраняват в една и съща база и се ъпдейтват автоматично. Освен това в един буфер може да пазите стойностите на няколко променливи. Предимствата на RRD е че всяка промяна се регистрира, като размера на базата не нараства линейно във времето.
До тук вероятно имаме лог с нещо такова:
/home/ivanatora/stats_ping/dir.bg.log

11/03/2009 00:05:01 : 0% loss to dir.bg Average: 7.271 ms
11/03/2009 00:10:01 : 0% loss to dir.bg Average: 9.091 ms
11/03/2009 00:15:01 : 0% loss to dir.bg Average: 7.466 ms
11/03/2009 00:20:01 : 1% loss to dir.bg Average: 7.152 ms
11/03/2009 00:25:01 : 0% loss to dir.bg Average: 8.273 ms
11/03/2009 00:30:01 : 0% loss to dir.bg Average: 6.863 ms
11/03/2009 00:35:01 : 0% loss to dir.bg Average: 11.690 ms

Този лог може да използваме за каквото си искаме, а може и въобще да не го правим. Горния скрипт работи ъпдейтва директно rrdtool, така че ако не искате излишни логове да се пазят на машината ви насочете $dump = "/dev/null";

Създаване на RRD бази.
За всеки изследван хост ще направим по една база. В тази база ще се съхраняват стойностите за Round Trip Time и Packet Loss.
Правим си следното bash скриптче (освен ако не ви мързи да го пишете на ръка за всяка база - може да имате и повече от три бази):

Подробностите за синтаксиса можете да намерите в документацията на RRDtool. На кратко - създаваме база с 2 източника на данни (променливи, които ще следим): PacketLoss и RTT. Задават се интервалите на ъпдейт на всеки източник,минимални и максимални допустими стойности. След това се правят 4 Round Robin Archives (буферите, за които говорихме по-рано).
Създаваме трите бази:

[ivanatora@~/rrd/temps/pings]$ sh create_script.sh bg
[ivanatora@~/rrd/temps/pings]$ sh create_script.sh gw
[ivanatora@~/rrd/temps/pings]$ sh create_script.sh int

Слагаме cronjob за изпълнение на ъпдейтващия скрипт на 5 минути:

*/5 * * * * perl /home/ivanatora/perl_razni/ping_stats.pl 87.120.194.1 gw
*/5 * * * * perl /home/ivanatora/perl_razni/ping_stats.pl dir.bg bg
*/5 * * * * perl /home/ivanatora/perl_razni/ping_stats.pl ivanatora.info int

Както видяхме скрипта приема два аргумента: адрес за ping и име на базата, която ъпдейтва.
Рисуване на графиките
Ще имаме отделна графика за всяка следена величина. Може да комбинираме няколко от графиките на една, но само ако очаквате там приблизително еднакви резултати. Големите отклонения на величините карат rrdtool да измества разделителната способност на графиката и една от графиките в общата картинка не се вижда добре. Ще имаме два скрипта за чертане на графики - един за Round Trip Time и един за Packet Loss.
/home/ivanatora/rrd/temps/pings/loss_graph.sh

/home/ivanatora/rrd/temps/pings/rtt_graph.sh

Тук можем да си поиграем с цветовете и крайния резултат да е доста eye-candy. Важните редове са DEF - където се извличат стойностите на променливите от базата и AREA - самото изчертаване. За повече подробности - документацията на RRDtool.
След това правим един скрипт, който да задейства изчертаване на всички графики:
/home/ivanatora/rrd/temps/pings/graph_all.sh

И поставяме съответната задача в crontab:

*/5 * * * * sh /home/ivanatora/rrd/temps/pings/graph_all.sh

В резултат всичките изображения се намират в директорията pings/img/. Остава да направим красива HTML страничка, която да събира всичко в едно.
Резултата можете да го видите тук.

Статията може да е скучна за доста хора, така че който го интересува да чете навътре

Има различни реализации на алгоритми за подобряване Качеството на услугата (QoS), които са известни още под името "планировчици". Повечето от тях използват клас-базирани опашки (CBQ) - трафика се разделя по класове. Всеки клас има лимит (част от общия лимит на връзката), който не може да се надвиши от сесиите, които попадат в класа. Различни планировчици са: RED, ECN, CBQ, HTB, WFQ, WRR, HFSC... "HFSC" означава "честна йерархична крива на услугата". Целта на алгоритъма е да гарантира адаптивно и гъвкаво изменение на трафика в реално време; плавно споделяне между йерархчно разположените класове. Какви са ползите от подобен тип алгоритъм:

• може да се направи филтър, който вкарва ACK пакетите в клас с по-висок приоритет. Така трансферите ще преминават с нормална скорост, дори и при натоварена връзка.
• може да се контролира забавянето на пакетите (latency) както и скоростта им на преминаване (bandwidth)
• може да се задават точни параметри на пиковите трансфери (burst), които са с малка продължителност, но използват връзката на максимум. Тези параметри включват големина на пика и плавното му намаляване след максимално определената продължителност. По този начин кратки трансфери ще преминават по-бързо (каквито са HTTP заявки и отговорите), докато големите трансфери ще се ограничават и няма да заемат целия капацитет на връзката.
• гарантиране поведение на услугата във всички крайни класове
• честно разпределение на свободния трафик към крайните класове

Планирането чрез HFSC се основава на два принципа: предаване на трафик в реално време, което гарантира сервизната крива на крайните класове и споделяне между класовете, което се стреми да разпредели свободните ресурси. Политиката на планировчика е да активира първия принцип, когато има опастност крайните класове да не могат да получат минималния им гарантиран ресурс. През останалото време е активиран втория критерий. За да се разбере принципа на действие на HFSC трябва да се вникне в няколко модела на управление на качеството на услугата.

Модел на управление качеството на услугата чрез сервизна крива

Сервизна крива - Service curve - това е графика на преминалите данни за единица време.

Кривата има три параметъра:

• m1 - наклон на първия сегмент
• m2 - наклон на втория сегмент
• d- пресечна точка на двата сегмента по оста Х

Според подобра на параметрите могат да се направят криви с различен наклон, вдлъбнати или изпъкнали. Вдлъбнатата крива работи добре с кратки пикове, които не стигат до максимално разрешеното време - точката d. Тази крива пропуска началото на трансфера и го ограничава ако се окаже че той не е пик, а изисква голям ресурс по цялата си дължина. Изпъкналата крива потиска първоначалния трафик и дава приоритет на връзки, които преминат точката d. Естествено може да се постигне и линейна сервизна крива, когато двата наклона са еднакви: m1 = m2.
Настройването на сервизна крива дава основен инструмент за управление качеството на услугата. Все пак това не стига за честно разпределяне на свободните ресурси между крайните класове.

Модел на виртуалното време

Всеки от класовете в йерархията има параметър vt - виртуално време, който представлява броя обслужени байтове за единица време. ВТ е въведено за първи път в PFQ (Packet Fair Queueing) алгоритъма и целта на параметъра е да синхронизира дъщерните класове в йерархията в принципа за споделяне на връзката. Когато стане възможно да се изпрати пакет се претърсва всеки от класовете в йерархията за най-малка стойност на виртуалното време. Крайният клас, който съвпадне с това изискване изпраща пакет и виртуалното време на този и на всеки друг клас нагоре по йерархията (до коренния клас) се увеличава. Винаги когато един клас изпраща пакет виртуалното му време се увеличава.

Модел на управление качеството на услугата чрез разпределяне и честна сервизна крива

Не само крайните класове, а всеки клас в йерархията има собствена сервизна крива. Целта е едновременно да се задоволят сервизните криви на крайните класове и излишъка от ресурс да бъде честно разпределен. HFSC използва този модел.
Всеки краен клас има следните три параметъра:

• d - максимално допустимото време на престой за пакет на края на опашката на класа
• e - желателното време за престой
• v - виртуалното време, свързано с класа

Класовете, които не са крайни имат само v параметър. Максималните времена на престой се изчисляват така че, сервизната крива е гарантирана когато всички пакети от дадена сесия имат време по-малко от d. Времето e се използва за избор на кой от двата планиращи принципа ще се активира за следващия пакет. Ако текущия пакет е престоял по-малко от времето e - продължил е нататък по връзката за кракто време, алгоритъма преценява има излишък от ресурс и се стреми да го разпредели. Ако текущия пакет е престоял повече от желателното време e, това е сигнал за потенциално претоварване и алгоритъма активира критерия за минимален гарантиран ресурс.

Имплементация в Linux

За контролиране качеството на услугата в Linux може да се използва инструмента tc, който е част от комплекта iproute2. Този документ няма да описва действието на tc и се предполага че читателите са запознати с него. Първата стъпка е да се инсталира обслужваща дисциплина (qdisc) към мрежовия интерфейс. Може да се добави и опция за използване на клас по подразбиране, в който ще попадне некласифицирания трафик. Общ синтаксис:
tc qdisc add dev $dev root handle $ID: hfsc [default $classID]
Пример:
tc qdisc add dev eth0 root handle 1: hfsc default 10
Добавяне на класове и изграждане на йерархия, чрез връзката parrent <-> classid.
Общ синтаксис:
tc add class dev $dev parent parentID classid $ID hfsc [ [ rt SC ] [ ls SC ] | [ sc SC ] ] [ ul SC ]
SC := [ umax bytes dmax ms ] rate BPS
Крайните класове могат да имат параметър за гарантиран ресурс в реално време (rt) както и параметър за сервизната крива, когато е активиран принципа за споделяне (ls). Вътрешните класове имат само параметъра ls, който е свързан с виртуалното време. Параметъра ul показва максимално заделения трафик, който може да попадне в класа. Параметрите rt и ls могат да бъдат изпуснати и вместо тях да се ползва описание на сервизната крива (sc). Тя се описва чрез:

• rate - скорост на предаване - височина на втория сегмент на кривата
• dmax - максимално закъснение - времето където се съединяват двата сегмента
• umax - скорост на предаване - височина на първия сегмент на кривата

Примерна йерархия от класове

tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit
tc class add dev eth0 parent 1:1 classid 1:10 hfsc sc rate 500kbit ul rate 1000kbit
tc class add dev eth0 parent 1:1 classid 1:20 hfsc sc rate 500kbit ul rate 1000kbit
tc class add dev eth0 parent 1:10 classid 1:11 hfsc sc umax 1500b dmax 53ms rate 400kbit ul rate 1000kbit
tc class add dev eth0 parent 1:10 classid 1:12 hfsc sc umax 1500b dmax 30ms rate 100kbit ul rate 1000kbit
Другата част, която не засяга HFSC планировчика и няма да бъде разглеждана е създаване на филтър, който да класифицира трафика.
Пример:
tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 80 0xffff classid 1:10

Имплементация в *BSD

HFSC за първи път бива вградено в open source решение за контрол качеството на услугата - това е ALTQ. ALTQ се използва в комбинация с пакетния филтър pf. Този документ няма за цел да описва пакетния филтър, така че ще се концентрираме върху HFSC. Използват се следните параметри:

• bandwidth - капацитета на връзката за даден клас. Стойността за bandwidth на дъщерните класове винаги трябва да е по-малка от bandwidth на родителския клас. Стойността за подразбиране на bandwidth е 100% от възможното за родителския клас. Стойността може да се задава в проценти, mbit, kbit...
• priority - приоритет на обслужване на класовете. Тази директива е прост начин за определяне на кои класове ще могат да изпратят пакет. Допустимите стойности за priority в HFSC и CBQ са от 0 до 7, като колкото по-високо е числото, толкова по-голям е приоритета. Също така priority влиза в сила когато връзката е натоварена и има опастност да не може да се изпълни принципа за гарантиране на минимална скорост.
• qlimit - брой "клетки" във FIFO опашка, използвана за запазване на изходящите пакети. Това се налага когато капацитетът на връзката не е достатъчен. В случай на насищане може да се случи някой от класовете да не може да предава. Тогава класовете запазват пакетите в определен брой клетки от паметта по реда им на пристигане. Когато се освободи ресурс, опашката ще бъде изпразнена навън. Използването на qlimit трябва да е само в крайни случаи, тъй като FIFO опашка противоречи на идеята за адаптивност и проспособимост на HFSC алгоритъма. Все пак запазване в паметта е по-добрата алтернатива от изпускане на пакети. Стойността на qlimit по подразбиране е 50.
• realtime - минимална гарантирана скорост, с която краен клас може да предава, независимо какво става с другите класове. Стойността на realtime може да бъде от 0% до 80% от общия капацитет на връзката.
• upperlimit - капацитет, който краен клас никога не може да надвиши.
• linkshare - същото като bandwidth, но важи само за вътрешните класове по йерархията. Ако за клас е сложена стойност на bandwidth, може да не се задава стойност за linkshare

Общ синтаксис за опашките в pf.conf:
altq on $interface $scheduler bandwidth $bw [priority $pri] [qlimit $qlim] queue { $q1, $q2, $q3...}}}

• interface - мрежовия интерфейс, където се инсталира дисциплината за обслужване
• scheduler - алгоритъм на планировчика
• bandwidth - капацитет на връзката. Задава се в b, Kb, Mb за bits, kilobits, megabits за една секунда. Стойността за подразбиране е 100% от капацитета на родителския клас.
• q1, q2, q3 ... - списък с имена на класове, които се описват по-долу

Общ синтаксис за описване на опашка (клас):
queue $name [on $interface] bandwidth $bw [priority $pri] [qlimit $qlim] $scheduler ( $sched_options ) { $queue_list }

• name - име на опашката. Трябва да съвпада с някое от имената на класовете, описани в списъка { $q1, $q2, $q3...} на родителския клас. Максималната дължина на името е 15 символа
• sched_options - допълнителни настройки и опции, които контролират поведението на планировчика
  • default - дефинира класа като клас в който попада всичкия некласифициран трафик. Трябва да има само една default дефиниция за всички класове, които са към един мрежов интерфейс.
  • red - активира алгоритъма Random Early Detection (RED) за опашката
  • ecn - активира алгоритъма Explicit Congestion Notification (ECN) за опашката
  • realtime $bw - задава параметъра realtime в HFSC
  • upperlimit $bw - задава параметъра upperlimit в HFSC
  • linkshare $bw - задава параметъра linkshare в HFSC

Примерна йерархия от класове

altq on rl0 bandwidth 744Kb hfsc queue { ack, dns, ssh, bulk, bittor, spamd }
queue ack bandwidth 80% priority 7 qlimit 500 hfsc (realtime 50%)
queue dns bandwidth 7% priority 6 qlimit 500 hfsc (realtime 5%)
queue ssh bandwidth 10% priority 5 qlimit 500 hfsc (realtime 10%) {ssh_bulk, ssh_login}
queue ssh_login bandwidth 90% priority 5 qlimit 500 hfsc
queue ssh_bulk bandwidth 10% priority 4 qlimit 500 hfsc
queue bulk bandwidth 1% priority 4 qlimit 500 hfsc (realtime 5% default)
queue bittor bandwidth 1% priority 3 qlimit 500 hfsc (upperlimit 99%)
queue spamd bandwidth 1% priority 2 qlimit 500 hfsc (upperlimit 1%)

Използвана литература

http://www.cs.cmu.edu/~hzhang/papers/SIGCOM97.pdf - A Hierarchical Fair Service Curve Algorithm for LinkSharing, RealTime and Priority Services
http://linux-ip.net/articles/hfsc.en/ - HFSC Scheduling with Linux
https://calomel.org/pf_hfsc.html - Hierarchical Fair Service Curve (HFSC) of OpenBSD
http://www.openbsd.org/faq/pf/queueing.html - PF: Packet Queueing and Prioritization

mplayer <опции>; xset dmps force off

След приключване на процеса на mplayer се изпълнява и втората команда, която управлява Power managment на монитора ви (standby, suspend, on, off) го изключва.

• DEL се държи като BACKSPACE - трие знака от ляво на курсора
• при натискане на DEL се изписва ?^ или ?H или нещо подобно
• при натискане на DEL просто не се случва нищо

Изметох Гугъл за отговори какво става с мен и накрая се оказа че имам полтъргайст в контролера на клавиатурата.
Майтап Ама се оказа че проблема с клавишите DEL и BACKSPACE е толкова заплетен, че чак ми стана чудно как в Windows и Linux до сега не съм имал проблеми. Ето ви един примерен документ да прочетете за какво става въпрос.
Е, оказа се че тъпия проблем има тъпо решение. Във Vim командата

:fixdel

оправя всичко и съответно може да бъде добавена в ~/.vimrc
За csh има подобна магия и това е:

if ($term == "xterm" || $term == "vt100" || $term == "rxvt" \
|| $term == "vt102" || $term !~ "con*") then
# bind keypad keys for console, vt100, vt102, xterm
bindkey "\e[1~" beginning-of-line # Home
bindkey "\e[7~" beginning-of-line # Home rxvt
bindkey "\e[2~" overwrite-mode # Ins
bindkey "\e[3~" delete-char # Delete
bindkey "\e[4~" end-of-line # End
bindkey "\e[8~" end-of-line # End rxvt
endif
bindkey ^? delete-char # for console
bindkey ^[[3~ delete-char # for xterm

Идеята на последните два реда обезмисля целия if-endif блок преди това. При мен работи само така - и с двете неща накуп

mencoder input.avi -ovc lavc -lavcopts acodec=ac3:abitrate=64:vcodec=mpeg4:vbitrate=300 -oac mp3lame -lameopts br=64 -vf scale=320:240 -of lavf -lavfopts format=mp4 -o output.mp4

Сега като го гледам този, не ми е чудно че не тръгва. Опитвам се да ползвам за аудио кодек АС3, а телефона май не го поддържа

mencoder input.avi -ovc x264 -x264encopts bitrate=350 -oac mp3lame -lameopts br=64 -vf scale=320:240 -o output.mp4

Едно време си мислех че x264 == MPEG-4, сега си мисля че не е точно така. Вече почнах да се обърквам кое е енкодер, кое е кодек и кое е контейнер...
Та това са само последните два от няколкостотин опита и килограми изхабени нерви по mencoder. Не искам да кажа че mencoder си върши работата зле - виновно е задклавиатурното устройство В други случаи mencoder върши чудесна работа, примерно това рипване на DVD:

mencoder dvd://3 -dvd-device /mnt/cdrom/ -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate="800" -oac mp3lame -lameopts br=128 -o dvd.avi

По едно време ми писна и се залових за алтернативния софтуер - ffmpeg. Не ми хареса man страницата му, където са описани по-малко от половината опции. Въпреки това, работата горе долу стана.
Първо пробвах да преобразувам клипчето в 3GP, но се оказа че формата има комплект валидни разделителни способности, най-високата от които да ми върши работа беше 176х144. Не мерси.
Съсредоточих се върху MP4:

ffmpeg -i input.avi -ar 8000 -ac 1 -acodec libfaac -vcodec mpeg4 -s 320x240 -r 24 -b 300000 -ab 48000 -t 30 output.mp4

Видеото излезе с подходящия thumbnail в мениджъра на телефона, даже и тръгна. Единствения кусур беше звука, който беше с отвратително качество.
Ето подобрение:

ffmpeg -i input.avi -ar 44100 -ac 1 -acodec libfaac -vcodec mpeg4 -s 320x240 -r 24 -b 250000 -ab 64000 output.mp4

Аудио енкодера не ми даде да вдигна аудио битрейта докато не вдигнах и sampling rate-а. Намалих и видео битрейта, понеже на някои места видеото забавяше и се получаваше framedrop ефект. Накрая всичко тръгна на сто процента

}
Помня че едно време си играх с arpwatch и той имаше някаква опция да праща отчети при смяна на MAC адрес по пощата, ама това не си е отчет ами просто някакъв дъмп от print_r() функцията в PHP. Шаш Изтриха се де:

# rm *0
# rm *1
# rm *2
.....
Сега да открия какво е оставило такива спомени там

2) Ако ядрото ви е наред, време е да откриете точно кое устройство ви носи UFS файловата система.

dmesg | grep bsd

Ще се види нещо като:

sdb1: <bsd: sdb6 sdb7 >

Тук Linux вижда 1 устройство - sdb1, но FreBSD си има по-особена организация на файловите системи. Вероятно сте запознати с това, така че ще ви го спестя. Да видим как са разпознати от boot процеса на Linux - sdb6 и sdb7.
Едното ми е swap дяла, а другото root на файловата система. Ако се съмнявам кое кое е, ще пробвам по отделно:

3) Монтиране с mount:
- изберете типа на UFS - при съвременните BSD-та (или поне на FreeBSD7) е ufs2

# mount -r -t ufs -o ufstype=ufs2 /dev/sdb6 /mnt/bsd/
# ls /mnt/bsd
COPYRIGHT boot compat dist etc lib media proc root sys usr
bin cdrom dev entropy home libexec mnt rescue sbin tmp var

Уцелих от първия път

4) Описване в /etc/fstab

/dev/sdb6 /mnt/bsd ufs ro,ufstype=ufs2 0 0

По желание можете да сложите
noauto - ако сте компилирали ufs support на модул вместо директно в ядрото
users - за монтиране от обикновени потребители без root привилегии

Липсва ми Web Developer добавката от FF. Тук има нещо подобно - Tools -> Advanced -> Developer Tools, но е далече от версията на FF.
В заключение на сравнението Opera <> Firefox (без да усетя съм почнал да ги сбивам ) ще кажа че Opera ми изглежда като всичко добро от FF събрано на куп и на стероиди. Бързината на зареждане - ако някога FF стигне до там, ще стане революция.
И все пак навика си е навик, и ако в някой скорошен ъпдейт на FF оправят забиванията и memory usage-то - пак ще почна да си го ползвам.

Харесаха ми:
1) 18 000 приложения в port системата. Това число се увеличава.
2) Светкавичната инсталация на прекомпилирани пакети.
3) Елементарния механизъм на прекомпилация на ядро.
4) Дори и да се забрави нещо при конфигурацията на ядрото - то ще бъде компилирано на модул.
5) В ps -Af мернах процес с PID - число по-голямо от 65535. Което ме изненада, защото в Slackware номерата на процесите след 65535 се връщат обратно и започват от 0 - където има свободно число. Не знам защо го споменавам като плюс, просто ме изненада приятно.
6) Има съвместимост с конфигурационните файлове на всяка *nix система. Примерно, взех си всичките скрити папки от /home/ivanatora на линукса, и си ги копирах тук. Резултат - всичките програми работят със същите настройки, с каквито са били преди - на другата система.
7) Монтира без проблеми FAT/NTFS/EXT2/3 с права за четене и запис.
8 ) Документация - на всичко. Тук man pages са издигнати на едно доста по-високо ниво - това не са само справочници за опциите на приложенията. Това вече си е пълна документация на почти всеки процес, който протича в системата. Примери:
man rc - информация за организацията на стартиращите rc скриптове
man ports - информация за портовете - какво представляват, как се работи
man rl - информация за Realtek лан карти Доста хардуер е описан по този начин, което си е HOWTO за пускане и работа.

Заключение: FreeBSD е идеално за домашна система. Лесен ъпгрейд и поддръжка - това ми беше липсвало до сега