@Div100 Да, открытая точка Wi-Fi - как раз традиционное место утечек. Поскольку все участники находятся в одном физическом домене сети, они видят пакеты друг друга. А далее пакеты собираются сниффером (да тем же Wireshark или tcpdump) и обрабатываются.
@Div100 С технической стороны идентифицируется нужный TCP stream, да и записывается куда-нибудь для дальнейшей обработки. Если Вы Wireshark установите, то тоже так сможете делать с трафиком, который проходит через Вашу машину.
@Shadow_wayfarer Да, конечно. На SlideShare, кстати, полно всяких презентаций - поглядите их как пример, можете также записи каких-нибудь известных спикеров посмотреть, чтобы составить примерную картину того, как должна выглядеть хорошая презентация.
@Div100 если трафик не зашифрован - он просто прослушивается на узле, через который он проходит. Если зашифрован - тоже прослушивается, но с гораздо меньшей эффективностью - что толку прослушивать белый шум.
@Div100 Как это "неважно"? А кому нужны зашифрованные данные? Только тем, у кого есть (или будет, в случае отсутствия в имплементации поддержки perfect forward secrecy) ключ. Технически - вообще никаких проблем нет. Стоят у провайдеров специальные ящички и записывают какую-то часть трафика в архив. Никакой это не MITM, MITM - это, например, подстановка сертификата третьим лицом по пути маршрута следования пакетов.
@Sali_cat Ну, зависит от того, какой размер у кэширующего SSD, у меня есть хранилища, на которых 2x600G размер кэша - вот там все вообще отлично. Вообще, надо тестировать каким-нибудь одинаковым тестом и сравнивать - навскидку сложно сказать, это же не только от SSD/не SSD зависит, а от количества и скорости вращения HDD. SAS 15K лучше обычных SATA примерно в два раза.
@Sali_cat Для такой задачи гибридное хранилище с writeback кэшем на SSD хорошо подойдет, все Ваше хранилище сессий целиком влезет в кэш. Но, если будете делать writeback кэш на SSD - делайте его на зеркале из двух SSD, иначе легко потерять вообще всю файловую систему.
@Sali_cat Я не имел дело с PCI-E SSD по причине их очевидной бесполезности для моих задач. Под базы данных мне хватает гибридных SSD+SATA и SSD+SAS хранилищ, а под большие объемы данных ничего не подходит лучше старого доброго SATA.
О том, как читать план запроса, написано в стандартной документации PostgreSQL. О том, как использовать статистику индексов - написано на PostgreSQL Wiki. Не знаю, что тут еще можно подсказать. В документации все нормально описано (кстати, не помню, читал ли я ее когда-нибудь вообще).
@opium Да хоть десять кластеров с приложением - если проект упирается в nginx, значит, что-то не так. Что я, кластера с приложением никогда не видел, что ли? Ну а раздача гигабита статики - это и есть тот самый необычный сценарий, который приводит к написанию собственных патчей к nginx, в конце концов. :) Правда, для патчей нужна полоса посерьезнее гигабита.
@etojemph Вообще, в современном C++ уже есть некоторые средства для организации беспроблемной работы с памятью - shared_ptr из библиотеки Boost, например. Вот только придется изучить еще и Boost (и C++ templates, конечно). Мне кажется, это более трудозатратно, чем C# или Java.
@opium Чтобы распределять нагрузку по ядрам - надо сперва ее получить, а получить нагрузку именно на nginx - ну, я знаю как, но это несколько необычный сценарий его использования. В крайнем случае можно припинить процесс на ядро, чтобы его планировщик не болтал, но вот чтобы с nginx у меня до этого доходило - не припоминаю.
