>> Разница в том, как это выглядит перед пользователями, если делать настолько же
>> удобно для тупого пользователя, как начали делать в subj-вом проекте. Там
>> нет необходимости заходить сначала на guest-а, чтобы получить ник, а только
>> потом логиниться с данным ником. Можно сразу заходить с новым ником.
> без разницы. те, кому это «с разницей», с воплями убегут уже от
> одного вида терминала.Моя девушка не убегает от вида терминала. Но осилить идею захода из под guest-а для регистрации она уже может не суметь.
>> Предлагаете в motd высветить запрет использования root или как?
> зачем? ник занят — это получается само просто потому, что система проверяет
> существующих пользователей. ну, если кому-то нечего делать — пусть долбится и
> пытается угадать ключ. авось умрёт от истощения.
Если делать без guest-овой учётки (то есть сделать мега-костыль в pam, разрешающий логиниться каждому незнакомому пользователю), то попытка залогиниться из под уже занятых логинов будет неуспешной, но без разжёвывания причины в достаточной мере, чтобы понял тупой пользователь (который впервые сталкивается с ssh).
Но я так понял, вы настаиваете на том, чтобы заходить сначала из под guest-а, так что ладно, пусть данная проблема пока будет неактуальной.
>>>> Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что
>>>> будет использовано намного больше ОЗУ.
>>> «намного больше» — по сравнению с чем?
>> В сравнении с хорошо написанным сервером, который всех обрабатывает одним процессом (но
>> не потоком).
> без проверок это чистой воды спекуляция. думаю, нет особого смысла обсуждать, не
> имея в руках чисел.
Ок, согласен.
>>> я повторно скажу, что большинство страниц будут shared.
>> 1. Страница - это обычно от 4КБ. Изменяем один байт и все
>> 4КБ сжирают дополнительную страницу.
> и фиг с ним. сто пользователей — 400 кб. да полноте, пусть
> даже четыре мегабайта. тысяча — сорок мегабайт.
Думаете изменённые байты уложатся в 100 страниц? Мне кажется, это аналогичным образом требует проверки. Не удивлюсь, если и 500-1000 страниц будут отличаться (там один int изменился, там один uid_t, там один static pid_t, там один char* через отдельный malloc() и т.п.).
>> 4. Это мелочь, но всё-таки проблема не только в fork(), но и
>> в том, что будет больше разных процессов. Каждый раз будет иметь
>> свои какие-то прилинкованные библиотеки, "обёртки" (для обработки аргументов, конфигов
>> и т.п.), реализации интерфейсов для взаимодействия между процессами и др.
> всё это как раз и идёт в shared. shared libraries — они
> ещё и потому shared, что система умеет их mmap'ить. если, конечно,
> сборщик потрудился их с -fPIC собрать.
1. Не всё, а только so-шки. Тот же дополнительный интерфейс между клиентом и сервером никуда не исчезнет, ибо в случае с subj-вым решением его просто нет (так как "клиент" и сервер -- это один процесс).
2. Я в курсе по поводу so-шек, но я видать криво выразился про нагрузку разными so-шками (ибо программы разные). Иначе я бы не писал, что это мелочь :)
>> Да, я это предполагал такое решение в другом комментарии выше. Но тогда
>> начинается новая волна проблем:
> один из вариантов. а вообще — ну, будет куча пользователей в системе.
> ну и что? как часто надо усердно читать соответствующие файлы глазами?
Всякие useradd и иже с ним работают очень медленно (проверенно на Debian/Wheezy).
> и что мешает при нужде выгрепнуть оттуда всех, у кого в
> login shell клиент прописан? да пусть будут. ну реально, обработать текстовый
> файл даже с сотней тысяч строк, учитывая, что это надо далеко
> не каждую минуту даже… пофигу. нет в этом никакой проблемы. ну,
> уйдёт на логин пол-секунды.
IMHO, просто это слишком серьёзное замусоривание системы ради всего лишь чат-сервера.
>> уже почти 1200 star-ов на github-е, что очень много для столь
>> молодого проекта (проекту лишь почти месяц).
> на гитхабе обитают идиоты. три с половиной нормальных и идиоты.
Ну, не думаю что возможна конструктивная беседа на эту тему :)
>[оверквотинг удален]
>>>>> эти люди покрутят пальцем у виска.
>>>> Не надо мешать в одну кучу пользователей и администраторов сервиса.
>>> и где я смешивал?
>> Тем, кому запрещают ставить другой софт -- это пользователи. А те, кто
>> делает решение -- это администраторы.
> я мягко намекаю на то, что те, кто могут сделать решение не
> через задницу, не испытывают в нём нужды. если пользователю нельзя ставить
> софт — значит, пользователь использует технику работодателя. в любой нормальной
> конторе необходимость нечто доставить для работы решается без проблем. а если
> оно для работы не надо, а надо, чтобы заниматься ИБД… тьфу.
Ставить ПО нередко запрещают по чисто бюрократическим причинам (например в некоторых НИИ, где регламентирующая документация сформулирована ещё в СССР и до сих пор действует). И обойти их иногда представляется весьма маловозможным. А надо оно для возможности связаться со знакомыми для консультации по запуску каких-нибудь MCNP (чтобы не диктовать длинные строки по телефону).
>> То есть с вашей точки зрения лучше никакое "решение", чем такое. Я
>> правильно понял?
> совершенно верно. потому что сабж — не решение, а куча говна. причём
> куча говна, которая «решает» несуществующую проблему.
>>> и какая разница? шифрование везде делается библиотеками в машинном коде, а всё
>>> остальное совершенно некритично.
>> Почему некритично?
> потому что дальше всё всё равно упирается в скорость сети.
Всякие там blowfish-cbc вроде как достаточно быстро работают, IIRC. А вообще в том же hpn-ssh бывает алгоритм шифрования "none".
>> Шифрование бывает легковесным. Например, есть всем известный hpn-ssh.
> э… это, кагбэ, прямая противоположность «легковесному». оно как раз предназначено
> для того, чтобы по максимуму жрать процессор, который иначе простаивает.
Память подвела (возможно как раз из-за наличия шифрования "none" в hpn-ssh). Опять же, прошу извинить.
>> IIRC, я утилизировал Gbps, используя scp на i7 (на клиентской стороне)
>> и ещё много ресурсов CPU осталось свободными.
> если кто-то сможет печатать с такой скоростью, пусть даже не особо осмысленно…
> мы всё ещё о чате говорим?
>> А пока давайте поделим на 1000, чтобы дойти до уровня сравнительно
>> высоконагруженного чат-сервера. Хотите сказать, что RPi в 1000 слабее i7 (в
>> рамках данной задачи)?
> вообще-то, загрузить в максимум одно соединение и загрузить сотни — задачи совершенно
> разные. по многим причинам — начиная от замусорености кэшей процессора.
Я в курсе. Но если "shared" действительно будет работать, то кеш (не включая всякие TLB и прочие тонкости) будет существенно эффективнее* . Но что ещё важнее, если представить, что всё обрабатывается одним процессом как в subj-вом решении (а не большим множеством процессов, как предлагаете вы), то тогда кеш будет намного эффективнее по нескольким причинам, наиболее важной из которых является то, что полных переключений контекста будет намного-много меньше.
* наталкивался на статью, где рассказывали про возможность timing attack через l3 cache за счёт дедупликации памяти (могу найти если нужно), то есть как минимум l3 кеш сохраняет эффективность между разными контекстами, если используется одни и те же физические страницы
Но в целом, я вашу позицию понял.
