makag

Не вижу смысла заморачиваться над разработкой костыля. Я бы вам советовал на ноутбуке обустроить apache (XAMP, LAMP, MAMP) и превратить его в свой "карманный" сервер с блек-джеком и bat-файлами. Так Вы сможете попросить друзей с сматфонами других производителей, размеров и народностей тоже поглядеть на ваши труды.
Однако если вы не хотите морочиться с установкой и отладкой MySQL, apache, PHP + phpadmin, хотя для web-разработчика это, пожалуй, первая проверка на прочность (я в свое время так заморочился, что пропало все желание это повторять), то на много проще будет разместить свой сайт на бесплатном хостинге.
Пройдя простую регистрацию и познакомившись с FTP-клиентом (FileZilla, например) для вашего хостинга (опять же неотъемлемая часть жизни web-разработчика) Вы через 30 минут от прочтения этого поста сможете поделиться с нами ссылкой на Ваш сайт и затестим все вместе ;)

Как опытная Ванга, скажу, оперативы у вас мало, в вашем кейсе минимум надо 8, а для комфортной работы 16, вы взяли классический дорожный ноут, к тому же в самой бютжетной его части и пытаетесь выжать из него то, чем должен заниматься полноценный рабочий комп.

В Mac OS X сейчас для работы нужно минимум 8GB памяти. 4GB это чисто в браузере посидеть. Смотреть сколько памяти свободно или занято — бесполезно. Просто попробуйте увеличить память и увидите разницу.

В основных браузерах куки хранятся в SQLite бд, а не отдельными файлами. То есть в случае обычного вируса/трояна на компе, максимум можно отслеживать попытки доступа к этой бд. В случае вредоносного кода на сайте - вы никак не сможете отследить, потому что доступ к кукам будет через стандартные механизмы браузера и ничем от правомерного доступа отличатся не будет. Имхо, для отслеживания кто, когда и к каким кукам обращался нужно вносить изменения в код браузера, обычным аддоном это сделать не выйдет. Как по мне это бессмысленная затея: для борьбы с кражей кук через js давно придумали HTTP-only куки, а для борьбы с зловредами существуют антивирусы.

Я использую IPv6 уже года, наверное, три. Конечно, это все ненативные адреса, а либо через тунель-брокера, либо через 6to4.
В любом случае, RIPE очень сильно рекомендует выдавать /64 конечному клиенту. В реальном же мире, выдают либо одну /64, либо две /64 (чтобы маршрутизацию можно было просто настроить, на самом деле и одной /64 хватает, а в локалке маршрутизировать через link-local адреса), либо что побольше, /60 или /56. Узнать, какой именно диапазон выдается клиенту несколько проблематично, тут только логика и интуиция, ну и гуглинг по провайдеру. Поэтому банить нужно сразу всю /64.

Единственное преимущество хранения файлов в БД, на которое нужно обратить внимание — это конкурентный доступ. То есть СУБД корректно обрабатывает одновременный доступ на изменение к одной и той же записи. Если конкурентный доступ маловероятен, то лучше использовать файлы.

Преимущество файлов:
— Бэкапить файлы не намного дольше, но восстанавливать можно по отдельным файлам, а не заливать весь дамп.
— Обращение к файлам и считывание быстрее, чем получение записи из БД (даже если используются сокеты).
— Кэширование файлов осуществляет автоматически ОС и сервер (можно использовать и опкэшер для контроля). А у СУБД кэширование больших файлов вызывает потерю производительности из-за вытеснения простых запросов из кэша.
— Количество файлов может быть очень большим без потери мощности сервера. У меня один раз хранилось около 12000 файлов в одной директории и ничего — сервер считывал без всяких задержек. Конечно вручную открыть эту папку было проблемно.
— Sphinx — свободно ищет по файлам.

Но при всех преимуществах файлов конкурентный доступ может испортить всю «малину», так что отталкивайтесь от него.