Мы называли эти машины «Электроника-60». Возможно, это была какая-то модификация. Памяти, действительно, было мало, но точные цифры сейчас уже не скажу. У нас была плата дополнительной памяти, и мы на ней иногда делали RAM-диск. Хотя не уверен, что это было за пределами 64K.
Полноценной многопользовательской работы не было. Для этого нужна была многопользовательская операционная система RSX-11. У нас была RT-11 и её локализованные аналоги. Многопользовательским был только Бейсик. Дополнительные терминалы подключались только когда он был запущен.
Да, директор был большим энтузиастом. Конечно, сошлось несколько факторов. Спонсором нашей школы (или «шефом», как тогда говорили) был воронежский завод «Процессор», который как раз выпускал эти компьютеры. Но такую возможность надо ещё уметь и хотеть использовать. Директор использовал и это, и многое другое.
Он сам очень увлёкся и сидел программировал. Самым интересным его проектом была программа для расчёта школьного расписания. В августе каждого года кабинет информатики был завален распечатками черновиков расписания. Задача очень сложная, особенно когда её решаешь в реальных условиях, с пожеланиями от учителей, ограничениями на кабинеты, отсутствие «окон» у учеников, спаренные уроки, и т.п.
Спасибо. По #1 — для добавления поддержки нового провайдера требуется зарегистрировать сервис у этого провайдера (получить ключи доступа) и реализовать механизм псевдо-аутентификации (вызовы API этого провайдера). Плюс управление учетными записями пользователей (например, слияние аккаунтов из разных провайдеров). В целом, это несложный процесс, и для многих языков программирования существуют пакеты, которые это упрощают. Но автоматического добавления нового провайдера по одному клику стандарт OAuth не поддерживает.
По #2 — такое предусматривает расширения новейшего стандарта OpenID Connect (http://openid.net/connect/) — посмотрите в секциях Discovery и Dynamic Registrations. Думаю, что в скором времени появятся реализации того, что вы описали, если, конечно, это окажется востребованным.
Зависит от конкретной ситуации, но если нужно аутентифицировать пользователей в RESTful APIs, то логичнее всего будет использовать токены. Как я уже писал, в этом случае клиент (мобильное приложение, браузерное JavaScript приложение или серверное приложение) должно предварительно получить токен от сервера аутентификации. Посмотрите пример архитектуры вот тут: identityserver.github.io/Documentation/docs/overview/bigPicture.html
Аутентификация по паролю -> HTTP authentication -> Kerberos (схема Negotiate).
В этом случае пользователю не придется дополнительно что-либо вводить для аутентификации: браузер автоматически аутентифицируется используя Kerberos тикет, полученный от AD при логине в Windows (по сути это вариант аутентификации по токену). На стороне веб-приложения мы сможем получить информацию о доменном аккаунте аутентифицированного пользователя.
Каждый разработчик может использовать любой инструмент на свой вкус. Auto Layout становится популярнее, несмотря на то, что непрост. Значит, вопрос, как обуздать его сложность и решить некоторые скрытые проблемы, остается актуальным.
Все же приходится, т. к. без Auto Layout большинство современных, пусть и простых интерфейсов, построить не получится. Пока еще есть возможность не использовать Auto Layout, но в будущем ее могут убрать, как в Android убрали Absolute Layout. За разнообразие размеров устройств приходится платить.
Закон действительно есть, только не вступил пока в силу. Да и касается он исключительно собак, а пропадают не только они. Хоть Harvey's Army изначально и фокусировались на поиске собак, сейчас они помогают искать любых питомцев.
EJB там остался большей частью исторически, т. к. был нужен на одном из этапов разработки. Уже есть версия на spring-boot без EJB, и DeviceHive 2.0.2 будет без него по умолчанию.
Аутентификация на сервере происходит при помощи DeviceId и DeciveKey, т. е. имя пользователя/пароль. Устройство фактический является пользователем в системе DeviceHive. В DeviceHive имеется продуманная модель безопасности, которая позволяет ограничивать доступ к сетям, устройствам, вызовам API, фильтровать по IP/доменам, ограничивать количество попыток входа в систему, блокирование попыток подбора пароля, SSL/TLS-подключения.
Только если без вашего ведома неожиданно поменяли параметры Wi-Fi-сети. И то можно с ноутбуком пробежаться до каждого устройства, подключив три провода/разъем, прописать новые параметры.
А во всех остальных случая, можно дать команду на использование новой Wi-Fi-сети удалено, затем поменять параметры роутера, и все девайсы прицепятся к новой сети.
Возможность выбора — всегда хорошо. DeviceHive — на 100 % открытый. Все исходные коды сервера можно посмотреть, изучить, а, если хотите, и поправить под свои нужды. Лицензия MIT. DeviceHive признан мировыми лидерами: Microsoft, Canonical. Вот свежая статья на Forbes: www.forbes.com/sites/janakirammsv/2015/05/12/canonical-and-ge-announce-smart-fridge-powered-by-snappy-ubuntu-core
Множество частных компании используют DeviceHive в коммерческих проектах. Более того, на примере этой прошивки мы предлагаем комплексное решения для реального железного воплощения интернет вещей, а не просто абстрагированный от реального оборудования клауд.
А вот тут и начинаются прелести использования DeviceHive в качестве сервера. DeviceHive можно развернуть на любом сервере с помощью докера за считанные минуты — registry.hub.docker.com/u/devicehive/devicehive
При этом нет никакой необходимости в интернете. Иначе говоря, инфраструктура может находиться целиком внутри локальной сети.
Производить сколько-нибудь сложные вычисления на esp8266, разумеется, не стоит, т. к., например, в случае изменения алгоритма придется перепрограммировать каждую, а в случае сервера — все управление на нём. esp8266 — лишь прозрачный шлюз между электрическими сигналами и программой, а сервер — центр управления.
Дальность приёма — понятие растяжимое, зависящее от множества факторов. Но прелесть использования Wi-Fi в том, что он уже очень часто есть готовый. Наверняка у 99.9 % читателей он есть дома. Для удалённых помещений, будь то Wi-Fi или любой другой способ связи, всегда будут возникать трудности с прокладкой проводов/установкой шлюза, причем роутер Wi-Fi — одно из самых недорогих решений.
У любого чипа, использующего Wi-Fi, энергопотребление всегда довольно велико. Однако т. к. у DeviceHive есть удаленный сервер, который сохраняет все команды, появляется возможность уводить esp8266 в спящий режим и пробуждать спустя какое-то время для запроса сервера на предмет команд, которые могли прийти, когда чип спал. Поэтому, исходя из логики реализуемого устройства (можно ли уводить чип в спящий режим на какое-то время) в некоторых случаях будет возможно получить довольно низкое энергопотребление.
Прошивка сейчас находится в разработке, и подобную команду для удаленной смены конфигурации, скорее всего, добавим на одном из этапов разработки. Но в любом случае стоимость USB->UART-переходника на Aliexpress, Ebay — от $1 с доставкой, соединять USB->RS232->UART нет никакого смысла.
Совершено верно: чтобы реализовать простейшее DIY-устройство, ничего, кроме esp8266, не нужно. Конфигурирование Wi-Fi сети и настроек сервера DeviceHive будет происходить через терминал по UART. В любом случае, в начале нужно прошить esp8266, а это делается через UART, т. е. можно, не отключая переходник от модуля, залить прошивку и сразу настроить её.
Сфинкс стал названием команды, так как связан с вопросами и ответами, навевал на нас ассоциации с мудростью и спокойствием. Подобными чертами мы хотели бы обладать как команда.
Полноценной многопользовательской работы не было. Для этого нужна была многопользовательская операционная система RSX-11. У нас была RT-11 и её локализованные аналоги. Многопользовательским был только Бейсик. Дополнительные терминалы подключались только когда он был запущен.
Да, директор был большим энтузиастом. Конечно, сошлось несколько факторов. Спонсором нашей школы (или «шефом», как тогда говорили) был воронежский завод «Процессор», который как раз выпускал эти компьютеры. Но такую возможность надо ещё уметь и хотеть использовать. Директор использовал и это, и многое другое.
Он сам очень увлёкся и сидел программировал. Самым интересным его проектом была программа для расчёта школьного расписания. В августе каждого года кабинет информатики был завален распечатками черновиков расписания. Задача очень сложная, особенно когда её решаешь в реальных условиях, с пожеланиями от учителей, ограничениями на кабинеты, отсутствие «окон» у учеников, спаренные уроки, и т.п.
По #2 — такое предусматривает расширения новейшего стандарта OpenID Connect (http://openid.net/connect/) — посмотрите в секциях Discovery и Dynamic Registrations. Думаю, что в скором времени появятся реализации того, что вы описали, если, конечно, это окажется востребованным.
В этом случае пользователю не придется дополнительно что-либо вводить для аутентификации: браузер автоматически аутентифицируется используя Kerberos тикет, полученный от AD при логине в Windows (по сути это вариант аутентификации по токену). На стороне веб-приложения мы сможем получить информацию о доменном аккаунте аутентифицированного пользователя.
А во всех остальных случая, можно дать команду на использование новой Wi-Fi-сети удалено, затем поменять параметры роутера, и все девайсы прицепятся к новой сети.
Множество частных компании используют DeviceHive в коммерческих проектах. Более того, на примере этой прошивки мы предлагаем комплексное решения для реального железного воплощения интернет вещей, а не просто абстрагированный от реального оборудования клауд.
При этом нет никакой необходимости в интернете. Иначе говоря, инфраструктура может находиться целиком внутри локальной сети.
Производить сколько-нибудь сложные вычисления на esp8266, разумеется, не стоит, т. к., например, в случае изменения алгоритма придется перепрограммировать каждую, а в случае сервера — все управление на нём. esp8266 — лишь прозрачный шлюз между электрическими сигналами и программой, а сервер — центр управления.
ru-chgk.livejournal.com/1616633.html
ru-chgk.livejournal.com/1617424.html