Я бы добавил линейную алгебру - "как определить, пересекает ли прямая линия треугольник, оба расположены в трёхмерном пространстве". Скалярное и векторное произведение векторов. Ну и много чего ещё.
А также понятие о временнОй сложности алгоритма... короче, весь список даже за ночь не написать.
Temp-User_0000, Мне интересно, понимаете ли Вы, что именно происходит при chroot? Ведь если ограничить юзера его каталогом - то он теряет доступ не только к данным остальных юзеров, но и к исполняемым файлам, библиотекам, конфигам (в /etc и много где ещё). Т.е. для запуска shell и команд из него - надо дать доступ ко всем нужным программам и ко всему, что им нужно; т.е. надо скопировать это к нему в каталог или использовать хитрые методы типа UnionFS.
Георг Гаал, Я полагаю, что топиккастеру надо смотреть в сторону назначения прав доступа. Настраивать chroot ему оказалось сложно. Возможно, ему надо настраивать контейнеры, виртуалки или типа того.
mt. NATS,
Первая строка - это команда для ввода в командную строку. Утилита curl есть под Linux/*BSD; а вот под Windows - не знаю, да ещё зависит от версии.
Остальные строки - это вывод этой команды.
Примерно то же самое можно получить командой telnet на порт:80 и вводом команд HTTP-протокола. А вот с HTTPS - telnet не прокатит.
Владимир Коротенко, Стандартная схема использования смартфона - однопользовательсткая, а защита идёт на уровне приложений. Механизм этой защиты - да, "песочница"; это вызывает большие проблемы при необходимости разделить какие-то данные между несколькими приложениями без права доступа к ним остальных приложениям.
Ваш пример не вяжется с условием "пока один человек подтверждает свою покупку". Потому что он подтверждает уже после того, как выбрал себе место и сообщил свой выбор продавцу-серверу.
Иными словами, порядок работы примерно такой:
Человек смотрит карту свободных мест и выбирает себе место.
После выбора места - оно резервируется, т.е. удаляется из списка доступных. Желательно сразу оповестить всех остальных людей, которые выбирают себе места в этом же зале.
Пока человек заполняет данные для оплаты - никто не может занять это место.
При обрыве соединения - место возвращается в список свободных. Если человек долго не подтверждает оплату - тоже так же.
Задача с выбором билета в кино - не решается в принципе. Можно придумать какие-то эвристики, снижающие вероятность ущерб от такого события, но они будут работать нестабильно.
Например, допустим, человек выбрал себе место - оно оказалось занято. Тогда сервер, обнаружив коллизию, на некоторое время резервирует этому человеку примерно такое же место.
Да, вводить ограничения по юзерам - это действительно стандартная практика. Однако, практика показывает, что эта практика не удовлетворяет потребностям - например, в Android есть всего один юзер, а разграничение доступа ведётся по приложениям.