Почему программисты допускают ошибки?

[Sla]

P.S. Глядя на АРМ банковских операционистов, магазинных кассиров, гостиничных администраторов и т.п., мне всегда казалось, что в принципе для подобных задач достаточно старинных 8-иразрядных PC типа Robotron или Spectrum в сети с одной машиной помощнее. При желании, даже отставая по элементной базе лет на 20, можно было бы массовым производством и соответствующими архитектурными решениями добиться качественных изменений в быту людей и деятельности многих предприятий.

У меня возникло какое-то дежавю. Где-то это я уже слышал. И вспомнил. Это мои первые мысли, когда впервые познакомился с банковским АРМом.
Но проблема уже не в 8-ми разрядных PC, а в их поддержке. А еще проблема в специализации.
Если Арм кассира требует только одной задачи, то Арм, вернее рабочее место, операциониста требует уже другого отношения к процессу.

зы Мне кажется я зря завел этот разговор 

[Dale]

Для автономной работы чего-нибудь 8-разрядного вполне могло бы и хватить, вряд ли там безумный объем вычислений. Но они же наверняка пожелают в сети работать, а полноценная поддержка стека TCP/IP требует ресурсов. Не знаю, как это выглядело бы на чем-то наподобие Intel8080 или Z80, а вот для AVR для работы в сети требуется подключить внешнее ПЗУ на 64К и внешнее ОЗУ, кажется, на 16К. Поскольку система команд AVR довольно эффективна, не думаю, что на других 8-разрядных микропроцессорах получится компактнее. А значит, для прикладных программ места останется совсем немного.

[Sla]

Вопрос не в автономности работы.
Работа с участием человека.
Был пример, за него и возьмемся.

Арм кассира.
Требования - поддержка сети.
Поддержка сети = авторизация.
Авторизация подразумевает наличие ЕДИНОГО авторизационного  центра, например домен.
Можно заставить работать рабочую станцию только с одним приложением. И в данном случае это правильно, соответственно и машинные ресурсы могут быть не требовательны.

Но если рассматривать АРМ "банковского" оператора, то возникает большая куча организационных вопросов.
Совмещение  в одном АРМе всех функций "рабочего" стола, например:
АРМ как ввод/вывод
Почта
Сервис мгновенных сообщений
Построители отчетов
Сервис третьих систем, например такиъх как системы срочных переводов, требующих интеграцию или в существующий АРМ, или наличие ПО от представителя услуг.

Количество информации, объем обрабатываемых данных  с каждым днем возрастает. Поэтому и появляются на рабочем месте монстры требующие W7 для колки орехов.

[Dale]

В принципе на рабочем месте можно поставить и что-нибудь поскромнее, если в центре стоит терминальный сервер. Тогда на столе оператора появится лишь небольшая коробочка "тонкого клиента", которая куда компактнее былых "Роботронов". Заодно и все перечисленные проблемы решатся.

Но это опять же неосуществимо техническими средствами 20-летней давности, к сожалению.

[Dimka]

Но они же наверняка пожелают в сети работать, а полноценная поддержка стека TCP/IP требует ресурсов.

В Интернет им выходить не то, что не надо, а нельзя. Для локальных же нужд можно использовать протоколы полегче.

Но это опять же неосуществимо техническими средствами 20-летней давности, к сожалению.

Это вопрос инфраструктуры. В развитой инфраструктуре использовать что-то старое, с ней уже не совместимое, крайне трудно и поэтому бессмысленно.

Помнится, в рассказе про историю АСУ Центробанка (тогда ещё Госбанка СССР) в начале описывалась машина, принимавшая данные из регионов аж по телеграфным линиям.

[Sla]

Dimka, а об выходе в интернет  пока речи не идет
Доступ к базе данных осуществляется на уровне каких протоколов?

и база может быть удалена от офиса за тысячи километров.

Помнится, в рассказе про историю АСУ Центробанка (тогда ещё Госбанка СССР) в начале описывалась машина, принимавшая данные из регионов аж по телеграфным линиям.

Не поверишь, и сегодня именно так и осуществляется...

[Алексей++]

А я то думаю, что терминалы у нас такие тормозные

[Dale]

В Интернет им выходить не то, что не надо, а нельзя. Для локальных же нужд можно использовать протоколы полегче.

TCP/IP - это не обязательно выход в интернет. А протоколы полегче могут создать проблемы с маршрутизацией, как только сеть разрастется за пределы пары сегментов. Опять же, сетевое оборудование поддерживает этот протокол как стандарт де-факто. Отход от стандарта ради экономии десятка килобайт у клиента может обернуться большими потерями в дальнейшем при расширении системы.

[Dimka]

Доступ к базе данных осуществляется на уровне каких протоколов?

Э, батенька... В таком раскладе, к примеру, Oracle-клиент и Robotron-1715 - вещи в принципе несовместимые Я ж говорю: от инфраструктуры зависит. Под железо и софт соответствующий, под софт - и железо. Моя мысль была посвящена не проблемам интеграции нынешних достижений науки и техники со старьём 20-30-летней давности, а тому, что внутреннее развитие софта и харда по сути не даёт никакого видимого эффекта в организации работы вышеперечисленных оперативных служащих, и с позиции этих АРМ капвложения в обновление софта и харда большого экономического смысла не имеют. Т.е. можно было бы достичь сходного результата за счёт одного лишь экстенсивного развития отрасли (в объёмах), без бурного технологического развития, которое мы наблюдаем. Впрочем, история сослагательного наклонения не терпит...

Как кто-то мне фразу представителя военной кафедры передавал: "Для начала научитесь в сортире ссать, не промахиваясь, а потом уже технологии осваивать будем." (К вопросу о той же элементной базе и надёжном массовом производстве. С этой точки зрения китайцы - молодцы, есть чему поучиться.)

Не поверишь, и сегодня именно так и осуществляется...

Не поверю, теперь у них Sun'овские сервера под Solaris. Я говорил не о проводах, а о непосредственном приёме машиной телеграфного кода.

[Dimka]

TCP/IP - это не обязательно выход в интернет. А протоколы полегче могут создать проблемы с маршрутизацией, как только сеть разрастется за пределы пары сегментов. Опять же, сетевое оборудование поддерживает этот протокол как стандарт де-факто. Отход от стандарта ради экономии десятка килобайт у клиента может обернуться большими потерями в дальнейшем при расширении системы.

Ты немного не о том думаешь. Рост сети имеет смысл для мощных машин, которые решают разнообразные задачи. Для АРМ'ов на слабых машинах - на их десяток обычно требуется одна более мощная серверная машина, которая, собственно, и выполняет основные расчёты и обработку; слабые машины лишь обеспечивают UI и могут подключаться к серверу хоть по COM - либо напрямую, либо в небольшом кольце. Не имеет смысла слабую машину выводить в большую изменяющуюся по конфигурации сеть, так как такая машина заточена лишь под ограниченный и практически неизменный набор функций.

[Sla]

Не поверю, теперь у них Sun'овские сервера под Solaris. Я говорил не о проводах, а о непосредственном приёме машиной телеграфного кода.

Для чего? Для хранения и обработки данных.
А данные как поступали по "проводам" так и поступают Файловый обмен.

Может мы говорим о разном?

[Dale]

Ты немного не о том думаешь. Рост сети имеет смысл для мощных машин, которые решают разнообразные задачи. ... Не имеет смысла слабую машину выводить в большую изменяющуюся по конфигурации сеть, так как такая машина заточена лишь под ограниченный и практически неизменный набор функций.

Я бы не стал так уж категорично. Взять ту же железную дорогу. Допустим, на полустанке стоит терминал системы продажи билетов, который должен быть подключен к некоему серверу, дабы не продавать билеты на одно и то же место многократно. Там же есть рабочее место диспетчера, который перецепляет вагоны к попутным составам. Он задействует другое приложение, возможно, на другом сервере. Допустим, есть еще телеметрия, которая оперативно передает состояние всяких стрелок-семафоров главному диспетчеру.

Длина кабеля СОМ - несколько метров. Ставить по серверу в тонну весом на каждый полустанок - дороговато и ненадежно. А вот нормальная сеть позволит каждому терминалу подключаться к своему серверу, не городя при этом сложную иерархию. И затраты на сетевое оборудование на каждом узле минимальны.

Надуманный пример? Хорошо, вспомнился еще один - сеть метеодатчиков, в которой каждая "машина заточена лишь под ограниченный и практически неизменный набор функций". И таких примеров из реальной жизни тьма.

[RXL]

Насчет дешевых процессоров и работы с сетью: недавно была тема про микроконтроллеры - рекомендую посмотреть ссылки в ней: https://forum.shelek.ru/index.php/topic,15897.0.html

Платы на ARM, встроенный контроллер ЖК экрана, поддержка сенсорных экранов, поддержка IDE, RS-232, USB и, что весьма важно - Ethernet 10/100. Цены умеренные. Поддерживается Linux-ом и WinCE. Если строить ПО по принципу тонких клиентов, то этого более чем достаточно.

Там же есть ссылка на PC-совместимые платы на процессорах VIA. Это на случай толстых клиентов.

[Люсь]

ни хрена вы наболтали!!! 6 страниц!!!...

[Dimka]

Люсь, в отличие от тебя, которая упорно молчит про неубывающие последовательности

[Dale]

Насчет дешевых процессоров и работы с сетью: недавно была тема про микроконтроллеры

Тут несколько другое направление тема приняла: не как сделать дешевле, а что мы смогли бы сегодня сделать в принципе, если бы до сих пор располагали лишь техникой советских времен. Под силу нам было бы решать сегодняшние задачи, располагая многотонными мэйнфреймами третьего поколения и рабочими местами на базе 8-разрадных кикропроцессоров?

[Люсь]

Offtopic:

Dimka, я на тебя кое-где обиделась. Ну и времени пока не было, и интернет кончился.
Твой код понять не могу, пытаюсь взять штурмом по-Альфовски, но пока тоже не получается.

Поставлю в угол.