Альтернативные дружественные оболочки

[digger]

У нас в мелких касса более старого образца, а машинка для карточек отдельно.Банку они платят, однако посетитель - нет.

[de_Trachant]

У нас кассы разве что прогружаются раз в полтора часа, загружая информацию из базы данных, а так не виснут (и опять тьфу-тьфу-тьфу)

[SiMor]

Вред очевиден, они стоят денег ,постоянно зависают и требуют старшей кассирши разблокировать.

Вообще-то даже такая архаичная штука, как "Экспресс-2", зависала редко.

[Нкоро_]

По крaйней мере в Израиле.Нормой я считаю,когда продавщица непрерывно работает.У нас постоянно касса по какой-то причине застряет и она ждет чего-то,а без рабочей кассы - никак.В докомпьютерную эпоху в суперах были механические кассы и аналоговые весы, цена выбивалась по этикетке.

Меняйте поставщика, однозначно. Не может быть, чтобы в Гипер-Израиле не было нормальных касс. Даже в заснеженной России, нормально иметь кассу со своей БД цен, сканером штрих-кодов и весами, причем с батарейкой на пару часов автономной работы. Например, такую. И они не виснут.

[SiMor]

Даже в заснеженной России, нормально иметь кассу со своей БД цен, сканером штрих-кодов и весами, причем с батарейкой на пару часов автономной работы.

ИМХО в России именно это и нормально, потому что ждут, что зависнет, а там исходят из того, что зависать не должно...

[Нкоро_]

ИМХО в России именно это и нормально, потому что ждут, что зависнет, а там исходят из того, что зависать не должно...

В заснеженной Германии наверное тоже, корионы не виснут. Еще бы они висли, немецкое качество есть немецкое качество :(

[Mamay]

Идеи "терминалы вместо компьютеров" выдвигались как минимум раз 10,и всегда проваливались.Во-первых, юзер попадает в рабство к поставщику.Во-вторых, любая сеть когда-нибудь тормозит.

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

[Лин]

На сколько я знаю в каждом уважающем себя банке внутренняя сеть построена по принципу терминальных сессий.

<{POST_SNAPBACK}>

Идентификация пользователей и хранение данных - да. Обработка же - бооольшой вопрос.

[Mamay]

Идентификация пользователей и хранение данных - да. Обработка же - бооольшой вопрос.

Не только большой, но и оч геморойный. Однако, на это идут ибо большая экономия получается на лицензионном ПО и аттестации АРМ по нормам безопасности.

[Нкоро_]

Не только большой, но и оч геморойный. Однако, на это идут ибо большая экономия получается на лицензионном ПО и аттестации АРМ по нормам безопасности.

Вот только к теме это не имеет никакого отношения, потому что оболочке все равно, на терминале она или где. Чтобы вернуться к теме - предлагаю развилку: Юникс не возник, изобретение пайпов произошло существенно позже появления доступных машин с графическими дисплеями, а идея текстовых конфигурационных файлов - вовсе не прижилась.

В результате, вместо написания командной строки и командных файлов имеем повсеместно вот это:

[krolik]

идея текстовых конфигурационных файлов - вовсе не прижилась

не верю(с)

[Нкоро_]

не верю(с)

Тем не менее, до массового юникса - было общим местом детально описывать задание - среду, исполняемый модуль, выделение памяти, пути ввода\вывода, библиотеки на динамическую линковку. Можно было объединять задания в пакеты, но в цепочки - только явно. Для понимания как ужасно это выглядело - курить мануал по EXEC

В принципе, оно возвращается - на новом уровне, через манифесты. Вот я и предлагаю - альтернативная дружественная оболочка это графическая утилита составления манифестов :rolleyes:

[Verr]

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

Вот как - то так.

Те ж яйца, только в профиль.

Вот захотел новый фильм посмотреть - и что, угадывать название вручную?

Нужно список выдать.

А если в списке всех фильмов строчек эдак миллион?

Поехала группировка (папочки)

Ну и копирование никуда не денется - новый документ не с нуля же набирать каждый раз.

И в чём, собственно, разница для рядового пользователя?

не верю(с)

Ну та же винда от этого почти ушла, они в ней скорей рудимент.

[krolik]

Ну та же винда от этого почти ушла, они в ней скорей рудимент.

xml

[SiMor]

Ну та же винда от этого почти ушла,

Регистры, имхо, скорее минус.

[Нкоро_]

xml

Что xml? C точки зрения идеологии и надежности от текстовых конфигурационных файлов не отличается, с точки зрения читаемости человеком - лютый, бешеный полярный лис. Программ, реально требующих в конфигураторе иметь древовидные структуры с тысячами ветвей и строить из них полное DOM-дерево - не так уж и много.

[Canis Dirus]

Вот только к теме это не имеет никакого отношения, потому что оболочке все равно, на терминале она или где. Чтобы вернуться к теме - предлагаю развилку: Юникс не возник, изобретение пайпов произошло существенно позже появления доступных машин с графическими дисплеями, а идея текстовых конфигурационных файлов - вовсе не прижилась.

Другая развилка: перекрывающиеся окна в графических оболочках так и не появились. Только Мытищи, только хардкор тайловые, вроде Xmonad:

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

[Нкоро_]

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

Более консервативное руководство Xerox, категорически отказавшееся тратить деньги на непрофильную деятельность вроде "создания идеального миникомпьютера просто так". Графический интерфейс все равно появится, но вот конкретно свободно двигающихся окон и мыши - может не возникнуть до того как одна ОС захватит рынок, а после уже поздно дергаться.

[digger]

было общим местом детально описывать задание - среду, исполняемый модуль

Это рукопашное построение задачи, меньше ресурсов компилятора и машины жрет.С повышением мощности отомрет.

перекрывающиеся окна в графических оболочках так и не появились.

Они и вышли из моды, когда МДИ поменяли на СДИ и докующиеся тулбары.Те же окна,вид в профиль.

[Нкоро_]

Это рукопашное построение задачи, меньше ресурсов компилятора и машины жрет.С повышением мощности отомрет.

Описание вручную количества страниц памяти несомненно отомрет, а граф ввода-вывода останется.

Еще из очевидных, но редко реализуемых идей - переворачивающиеся окна, с изнанки у них внутренняя консоль приложения и отладчик. У рабочего стола на изнанке системная консоль.

[digger]

Граф ввода-вывода,как я понимаю, имел смысл на больших машинах с канальной архитектурой.

[Нкоро_]

Граф ввода-вывода,как я понимаю, имел смысл на больших машинах с канальной архитектурой.

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

[digger]

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

[Нкоро_]

Обычно программа пишет в файл, другая из него читает.

На тогдашних малых машинах, - это немыслимые, до тысяч и десятков тысяч раз, тормоза. Магнитная головка мееедленно едет к нужной дорожке, про ленту промолчу. Пайпы и появились от желания получить на миникомпьютерах сравнимую с мейнфреймами (у которых IO занимались выделенные процессоры и память была многоканальная) производительность.

К тому же, где как не на ПК нам обрабатывать звук и видео?

[digger]

Да, аберрация, тогдашние реалии другие.Похожую картинку я видал еще в одной отрасли - визуальное построение квери в SQL.Когда связей мало, все пишется руками, и картинка выше тоже ,но когда много и они сложные - такая утилитка полезна.Еще туда подходит векторный дисплей .