> Просто из-за моей лени перечитать данную ветку комментариев, вместе с прочтением других
> веток комментариев, в моей голове сформировалась небольшая каша. Приношу извинения.ерунда, бывает.
> Разница в том, как это выглядит перед пользователями, если делать настолько же
> удобно для тупого пользователя, как начали делать в subj-вом проекте. Там
> нет необходимости заходить сначала на guest-а, чтобы получить ник, а только
> потом логиниться с данным ником. Можно сразу заходить с новым ником.
без разницы. те, кому это «с разницей», с воплями убегут уже от одного вида терминала.
> Предлагаете в motd высветить запрет использования root или как?
зачем? ник занят — это получается само просто потому, что система проверяет существующих пользователей. ну, если кому-то нечего делать — пусть долбится и пытается угадать ключ. авось умрёт от истощения.
>>> Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что
>>> будет использовано намного больше ОЗУ.
>> «намного больше» — по сравнению с чем?
> В сравнении с хорошо написанным сервером, который всех обрабатывает одним процессом (но
> не потоком).
без проверок это чистой воды спекуляция. думаю, нет особого смысла обсуждать, не имея в руках чисел.
>> я повторно скажу, что большинство страниц будут shared.
> 1. Страница - это обычно от 4КБ. Изменяем один байт и все
> 4КБ сжирают дополнительную страницу.
и фиг с ним. сто пользователей — 400 кб. да полноте, пусть даже четыре мегабайта. тысяча — сорок мегабайт. даже на плате с 512 это совершенно пофигу, она загнётся намного раньше.
> 4. Это мелочь, но всё-таки проблема не только в fork(), но и
> в том, что будет больше разных процессов. Каждый раз будет иметь
> свои какие-то прилинкованные библиотеки, "обёртки" (для обработки аргументов, конфигов
> и т.п.), реализации интерфейсов для взаимодействия между процессами и др.
всё это как раз и идёт в shared. shared libraries — они ещё и потому shared, что система умеет их mmap'ить. если, конечно, сборщик потрудился их с -fPIC собрать.
> Да, я это предполагал такое решение в другом комментарии выше. Но тогда
> начинается новая волна проблем:
один из вариантов. а вообще — ну, будет куча пользователей в системе. ну и что? как часто надо усердно читать соответствующие файлы глазами? и что мешает при нужде выгрепнуть оттуда всех, у кого в login shell клиент прописан? да пусть будут. ну реально, обработать текстовый файл даже с сотней тысяч строк, учитывая, что это надо далеко не каждую минуту даже… пофигу. нет в этом никакой проблемы. ну, уйдёт на логин пол-секунды.
>>> Ну, естественно модульное решение предпочтительнее. Но его кто-то уже сделал?
>> а никому не надо. сабжевое — тоже.
> Так пусть это решит свободное сообщество.
да пусть себе решает, разве же я кому могу запретить?
> уже почти 1200 star-ов на github-е, что очень много для столь
> молодого проекта (проекту лишь почти месяц).
на гитхабе обитают идиоты. три с половиной нормальных и идиоты.
>>>>> Лучше готового решения пока никто не написал.
>>>> потому что никому нафиг не нужно. ну, из тех, кто может сделать
>>>> нормальное решение. потому что если тем, кто может сделать нормальное решение,
>>>> заявят, что «на работе нельзя ставить софт, но можно ssh» —
>>>> эти люди покрутят пальцем у виска.
>>> Не надо мешать в одну кучу пользователей и администраторов сервиса.
>> и где я смешивал?
> Тем, кому запрещают ставить другой софт -- это пользователи. А те, кто
> делает решение -- это администраторы.
я мягко намекаю на то, что те, кто могут сделать решение не через задницу, не испытывают в нём нужды. если пользователю нельзя ставить софт — значит, пользователь использует технику работодателя. в любой нормальной конторе необходимость нечто доставить для работы решается без проблем. а если оно для работы не надо, а надо, чтобы заниматься ИБД… тьфу.
> То есть с вашей точки зрения лучше никакое "решение", чем такое. Я
> правильно понял?
совершенно верно. потому что сабж — не решение, а куча говна. причём куча говна, которая «решает» несуществующую проблему.
>> и какая разница? шифрование везде делается библиотеками в машинном коде, а всё
>> остальное совершенно некритично.
> Почему некритично?
потому что дальше всё всё равно упирается в скорость сети.
> Шифрование бывает легковесным. Например, есть всем известный hpn-ssh.
э… это, кагбэ, прямая противоположность «легковесному». оно как раз предназначено для того, чтобы по максимуму жрать процессор, который иначе простаивает.
> IIRC, я утилизировал Gbps, используя scp на i7 (на клиентской стороне)
> и ещё много ресурсов CPU осталось свободными.
если кто-то сможет печатать с такой скоростью, пусть даже не особо осмысленно… мы всё ещё о чате говорим?
> А пока давайте поделим на 1000, чтобы дойти до уровня сравнительно
> высоконагруженного чат-сервера. Хотите сказать, что RPi в 1000 слабее i7 (в
> рамках данной задачи)?
вообще-то, загрузить в максимум одно соединение и загрузить сотни — задачи совершенно разные. по многим причинам — начиная от замусорености кэшей процессора.
