kekoz

«разобрать» большую сеть — это не задача, для которой можно построить этапы.
Пока твоя задача — построить функциональную и логическую схемы сети, которую ты/начальство хочешь получить. А вот потом уже можно будет решать задачу вида “Как на имеющейся физической сети получить то, что функционально и логически уже спроектировано”.

А на удалённой базе разрешено коннектиться с других хостов?

Читать первоисточники:
На английском
На русском (допускаю, что традиционно чуть отстаёт по времени от англоязычной)

a. Сколько бит в ip-адресе?
b. Что «маскирует» маска?

a-b-2 и есть количество адресов, которые ты можешь назначать хостам.

Никак

А fsck попробовать, не?

Утяни /usr/src и пересобери только /usr/src/secure
Предупреждаю — это может и не проканать...

Похоже, у тебя /usr/ports не соответствует содержимому /usr/share/mk. Порты HEAD, а OS — 8.2-RELEASE

Отключи или правильно настрой firewall в XP

man неподъёмен? :)

echo -n "some shit..."

Дорогой трамвай, а с чего ты решил, что файл конфигурации ipfw является sh-скриптом? Сообщаю — он таковым не является. Он является скриптом самого ipfw. Таким образом, в нём могут содержаться только команды ipfw.

Кусочек из /etc/rc.firewall (где твой firewall_type="/etc/ipfw.conf" и "вызывается"):

*)
        if [ -r "${firewall_type}" ]; then
                ${fwcmd} ${firewall_flags} ${firewall_type}
        fi
        ;;

Программист пишет программу. На чём угодно, начиная от блок-схем и заканчивая простым русским языком. Программа в данном контексте — это не набор инструкций на том или ином языке программирования, а алгоритм действий, ведущих к достижению цели.

Кодировщик (кодер) воплощает этот алгоритм на том или ином языке программирования. Он даже может быть весьма далёким от математики человеком. Может быть полным деревом в математике (и алгоритмизации как её части).

На практике эти две ипостаси часто сочетаются в одном специалисте. Но есть нюанс — программист, который умеет записывать свои программы на том или ином языке программирования (суть кодировать) остаётся всё тем же программистом, но умеющим обходиться без кодировщика. А вот кодировщик, далёкий от математики и алгоритмизации, без программиста — безработный.

Сомнительно мне существование коробок, поддерживающих и PATA, и SATA. Хотя не скажу что сильно изучал этот рынок, потому могу ошибаться. Но сомнительно почему-то :)

wget с соответствующей обвязкой на любом скриптовом языке, хоть на /bin/sh

А чем не устраивают ffmpeg/mencoder?

Конкретных бенчей я не видел, а по моему разумению думается, что прирост по сравнению с i7 будет, а по сравнению с 4-головым зеоном — вряд ли.

Тут, правда, возникает ещё и куча вопросов более сложных :)
1. А что ты считаешь адекватным приростом?
2. А на каких конкретно операциях?

Одна виртуалка будет какую-нибудь СУБДу крутить, другая — числодробилка. Первой прироста 0 целых фиг десятых, второй — аж 10%.

>>А какие адреса используются во “внешней” локалке? kekoz, сегодня в 00:52
>172.25.xx.xx
>я настроил внутреннюю локалку роутера так же думая, что из этого что-нибудь выйдет.

В этом и есть твоя главная проблема.

Подключаться надо через WAN.

Теперь “на пальцах” показываю: если в твоей локалке используются те же адреса, что и во внешней (как, кстати, ты собирался разрешать конфликты ip-адресов?), то с точки зрения маршрутизатора обращения с твоих компов к компав внешней локалки не нуждаются в маршрутизации. А это значит, что пакеты рассылаются только по LAN-портам, в WAN-порт они просто не попадают. Решить задачу можно двумя способами:

1. proxy-arp. На все запросы из внешней локалки вида “Какой mac-адрес у хоста 172.25.xxx.xxx (xxx.xxx — твоей локалки)?” твой маршрутизатор на WAN-порте отвечает “Это Я!” Умеет ли это твоя железка, я не знаю, разбирайся сам.

2. ip-адреса в твоей сети должны быть из другого ip-пространства. Но это порождает следующую проблему.

Опять на пальцах показываю. Допустим, ты делаешь у себя внутри 192.168.25.0/24. С твоего хоста 192.168.25.5 ты пингуешь 172.25.25.25. Пакет попадает в твой маршрутизатор. Маршрутизатор видит, что пакет назначен в другую сеть, он его выбрасывает на WAN-порт. Там он попадает на 172.25.25.25. Тот рожает ответ на пинг. Пакет от 172.25.25.25 к 192.168.25.25. И куда он пойдёт? Откуда хосты во внешней локалке могут знать, что пакеты на 192.168.25.0/24 надо слать именно на твой маршрутизатор? А не знают они этого. И потому ответов из внешней локалки к себе ты не получишь. Здесь опять два способа решения:

1. Сделать так, чтобы внешняя локалка знала о твоей сети. Если ты не являешься администратором этой самой внешней локалки, то задача вряд ли разрешимая :) — требуется либо поднять там соответствующий статический маршрут, либо какой-то протокол маршрутизации (хотя бы RIP).

2. Пакеты из твоей сети должны выглядеть так, как будто они всё же из внешней сети. Вот это уже очень просто — это NAT. И это твой маршрутизатор стопудово умеет. Именно это ты и должен сделать.