Ну и ладно... Пусть будет «однооконный», но с красивыми шрифтами и с графикой!14.04.03 18:46 Число просмотров: 1114 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 14.04.03 20:03 Количество правок: 1
Пиктограммы — вещь сильная! И зрительная память сильнее словесной...
Мышь произвела революцию, чего бы там ни говорили…
Мне охота кое-когда, чтобы в одном месте шрифт был мелкий, в другом крупный...
SuperCalc была сильная досовая прога, но какое всё-таки уродство из-за того, что не видно как раз-таки «больших объёмов данных» из-за текстового режима монитора.
Вот Sparc stations — сурьёзные машины под *nix'ами, а у них в принципе нет текстового режима — даже при загрузке BIOS эмулирует его, бедняга ;-)
И чего упираться-то — против прогресса ;-)
Про маки и говорить нечего, там тоже самое, причём с 80-x годов ;-)
Разработчики видеокарт, я уверен, матерятся грязными ругательствами, когда им приходится реализовывать в железе «для совместимости» весь отстой типа видеорежимов MDA, CGA, EGA и проч ;-)
Теперь про командную строку...
Какая разница между двумя интерфейсами — старым (командной строки) и новым (графическим)? Принципиальной разницы между ними нет, оба содержат одну и туже ошибку реализации. Я объясню, что за ошибку... И тот и другой генерируют некие события для программ в зависимости от ввода (пользовательского или программного, когда, к примеру, отрабатываются скрипты, в которых вызываются программы с «параметрами» в командных строках). Дык вот если интерфейс командных строк из-за своей простоты ещё позволял такую автоматизацию в скриптах, то GUI упирается... Помнится, в Win 3.1 была такая прога, которая пыталась делать подобное для GUI, симулирая нажатия клавиш и клики мыши ;-)
А общая ошибка реализации в том, что не нужно программам самим «разбирать» ввод на низком уровне. Вот к примеру, в мелкософте, задумались немножко над этой проблемой, и состряпали VBS, в котором можно делать многие вещи, обращаясь к объектам OLE в скриптах... В программах должен быть некий «объектный» костяк, который можно вызвать в скриптах, а OS должна иметь некий сервис для программ, но не тупой «stdin, stdout, stderr», а нечто гораздо более «развесистое»... Ведь если вникнуть, параметры имеют чаще всего древовидную структуру, многие однотипны (типа On, Off), но относятся к разным объектам, поэтому приходится для командной строки придумывать разработчикам всякие извращения типа «BurstDevMode:on», некоторые параметры взаимоисключающие, что приводит к ошибкам в командных строках, из-за чего проги выдают «suspicious (клянусь, видал :-) parameters». А вот гуёвые ниспадающие древовидные менюшки, которые часто, к тому же, содержат некую бизнес-логику приложения (к примеру, некоторые disabled, некоторые radio-buttoned и т.п.), избавляют пользователя ушастого от многих ошибок... Компьютер ведь для человека, а не человек для компьютера, не для того, чтобы помнить тучу «BurstDevMode:on» — башки никакой не хватит.
Да и фанаты командных строк — которым по 30-35 лет, из них 10 седят в *nix'ах, так привыкли к своей любимой шелл, что пересади их на принципиально другую ось, пусть с командной строкой, но только с другими командами... Как говориться, старую обезьяну не научишь новым трюкам ;-D В этом плане «интуитивное» GUI, которое само протолкнёт юзверя куда надо, выигрывает.
Так что до идеальной OS что униху, что виндам, что другим осям, ещё далеко... В «грехе» было рождено множество софта, которому нужна «совместимость» — читай stdin, stdout, stderr ;-)) В «грехе» также и GUI, поскольку слабо может быть автоматизировано в том виде, в каком оно есть сейчас. Нужно нечто революционное и чтобы оно «пронизывало» OS, софт и человека на всех уровнях взаимодействия человек<->программа<->OS.
Полное администрирование служб и драйверов NT — зацените прогу, плз...11.04.03 21:18 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 11.04.03 21:19 Количество правок: 1
Если комп не в локалке (наличие туннеля PPP дело не меняет), то прога подвисает на некоторое время, подвешивая при этом панель задач - между окнами переключаться нельзя, кнопки дико мигают... абзац, короче. Через секунд 20 прога отходит, но в этом выпадающем меню нифига не появляется - а что там должно быть, кстати?
во вторник на работе запущу на локалке - поглядим, как она там запрыгает.
Так ведёт себя api netserverenum() с параметром max_preferred_length + sv_type_nt...12.04.03 21:03 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 12.04.03 21:06 Количество правок: 1
Не знаю, что тут можно придумать... Может буфер сделать маленький, чтобы поменьше серверов перечисляла за один раз... Но, по-моему, это лечится только отключением перечисления хостов в сети, если соединение низкоскоростное :-(
По-моему именно так всё и сделано в NTшном администраторе серверов — когда прокрыжена галка «подключение с низкой пропускной способностью» (вроде так), сервера не перечисляются.
В локалке всё рулез.
Делай это в отдельном потоке14.04.03 10:16 Автор: Killer{R} <Dmitry> Статус: Elderman
Посмотрел. Есть полезные фишки, которых нет в плагине. Жаль что гуй. Сильных багов вроде нету, кроме уже упомянутой Main->Host .
Не знаю, мне не жалко... в xxi веке живём, а людям до сих пор снится tty :) вот и zef тоже сны в ascii видит ;-))))))13.04.03 21:23 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 13.04.03 21:30 Количество правок: 2
А Far Manager я уважаю — мой любимый файл-менеджер, но по части плагинов не маньяк — пожалуй те, что с ним идут, пока удовлетворяют меня полностью, особенно для работы с архивами... С плагинами тоже не надо в крайности — недавно зашёл на сайт Far Group, каких там только нет, даже Winamp'ом управлять можно, только смысл это делать в Far'е?
Уж не помню где видел, но командная строка оказалась самым эфективным методом управления большими объемами данных14.04.03 16:43 Автор: amirul <Serge> Статус: The Elderman
Небольшой оффтоп, но на тему XXI века: многооконный интерфейс признали ненужным, потому как не помню точно цифру, но где-то порядка 95% времени окна в этом многооконном интерфейсе развернуты на полный экран, а это мало отличается от тех же виртуальных терминалов и скринов в юнихе.
Ну и ладно... Пусть будет «однооконный», но с красивыми шрифтами и с графикой!14.04.03 18:46 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 14.04.03 20:03 Количество правок: 1
Пиктограммы — вещь сильная! И зрительная память сильнее словесной...
Мышь произвела революцию, чего бы там ни говорили…
Мне охота кое-когда, чтобы в одном месте шрифт был мелкий, в другом крупный...
SuperCalc была сильная досовая прога, но какое всё-таки уродство из-за того, что не видно как раз-таки «больших объёмов данных» из-за текстового режима монитора.
Вот Sparc stations — сурьёзные машины под *nix'ами, а у них в принципе нет текстового режима — даже при загрузке BIOS эмулирует его, бедняга ;-)
И чего упираться-то — против прогресса ;-)
Про маки и говорить нечего, там тоже самое, причём с 80-x годов ;-)
Разработчики видеокарт, я уверен, матерятся грязными ругательствами, когда им приходится реализовывать в железе «для совместимости» весь отстой типа видеорежимов MDA, CGA, EGA и проч ;-)
Теперь про командную строку...
Какая разница между двумя интерфейсами — старым (командной строки) и новым (графическим)? Принципиальной разницы между ними нет, оба содержат одну и туже ошибку реализации. Я объясню, что за ошибку... И тот и другой генерируют некие события для программ в зависимости от ввода (пользовательского или программного, когда, к примеру, отрабатываются скрипты, в которых вызываются программы с «параметрами» в командных строках). Дык вот если интерфейс командных строк из-за своей простоты ещё позволял такую автоматизацию в скриптах, то GUI упирается... Помнится, в Win 3.1 была такая прога, которая пыталась делать подобное для GUI, симулирая нажатия клавиш и клики мыши ;-)
А общая ошибка реализации в том, что не нужно программам самим «разбирать» ввод на низком уровне. Вот к примеру, в мелкософте, задумались немножко над этой проблемой, и состряпали VBS, в котором можно делать многие вещи, обращаясь к объектам OLE в скриптах... В программах должен быть некий «объектный» костяк, который можно вызвать в скриптах, а OS должна иметь некий сервис для программ, но не тупой «stdin, stdout, stderr», а нечто гораздо более «развесистое»... Ведь если вникнуть, параметры имеют чаще всего древовидную структуру, многие однотипны (типа On, Off), но относятся к разным объектам, поэтому приходится для командной строки придумывать разработчикам всякие извращения типа «BurstDevMode:on», некоторые параметры взаимоисключающие, что приводит к ошибкам в командных строках, из-за чего проги выдают «suspicious (клянусь, видал :-) parameters». А вот гуёвые ниспадающие древовидные менюшки, которые часто, к тому же, содержат некую бизнес-логику приложения (к примеру, некоторые disabled, некоторые radio-buttoned и т.п.), избавляют пользователя ушастого от многих ошибок... Компьютер ведь для человека, а не человек для компьютера, не для того, чтобы помнить тучу «BurstDevMode:on» — башки никакой не хватит.
Да и фанаты командных строк — которым по 30-35 лет, из них 10 седят в *nix'ах, так привыкли к своей любимой шелл, что пересади их на принципиально другую ось, пусть с командной строкой, но только с другими командами... Как говориться, старую обезьяну не научишь новым трюкам ;-D В этом плане «интуитивное» GUI, которое само протолкнёт юзверя куда надо, выигрывает.
Так что до идеальной OS что униху, что виндам, что другим осям, ещё далеко... В «грехе» было рождено множество софта, которому нужна «совместимость» — читай stdin, stdout, stderr ;-)) В «грехе» также и GUI, поскольку слабо может быть автоматизировано в том виде, в каком оно есть сейчас. Нужно нечто революционное и чтобы оно «пронизывало» OS, софт и человека на всех уровнях взаимодействия человек<->программа<->OS.
В общем да, но я говорил о *больших* объемах15.04.03 15:06 Автор: amirul <Serge> Статус: The Elderman
Для "юзверя ушастого" лучше гуя ничего и не придумаешь. Но не всегда компьютер для человека, есть и специальные люди для компьютеров, сисадминами зовутся, некоторые еще и программерами и т.д..
А вот когда настроек становится несколько сотен, и еще больше твиков в реестре. Никакой гуй не помогает рыться по этим самым менюхам и искать что же тебе собственно надо. Командная строка дает например команду apropos для таких случаев. Кроме того виндовый шелл это не совсем sh или bash. В нем единственное что можно сделать это запустить какую-нить прогу, ну иногда перенаправить вывод в more. Хотя многие проги не выводят на stdout, а сразу пишут в консоль (хренов хедер conio.h).
Я вообще вырос на гуях и с юнихами знаком года 3 всего. И действительно мне трудно было учиться новым трюкам. Но буквально с первых же дней знакомства юних мне понравился.
Кроме того протоколы и конфиги в юнихах практически все плайнтекстовые, а в виндовых - бинарные. Выход со сниффера когда что-то не работает в CVS-е например мне понятен без дополнительных извращений типа калькулятора, подсчета байт чтоб найти нужное поле и т.д.
Текстовый дамп базы данных (и реестра в частности, тоже ведь БД), лог апача или файрвола или IDS-а (да и куча других текстовых логов) есть много примеров того, где гуй и рядом не валялся. Если бы лог можно было анализировать только в той же оболочке, которая его и генерит, то это бы существенно ограничивало гибкость. Мне вот например часто не хватает средств стандартного regedit-а а деться некуда - база бинарная, да к тому жа залоченная. Хотя реестр еще ладно, чтоб разгребать такие горы мусора, которые валяются там, из соображений эффективности его нужно было сделать бинарным. А я видел не меньше десятка анализаторов лога для апача. А можно и вообще без них. vi имеет средства для поиска строки в тексте - и вперед на мины. Или можно grep-ом.
Короче, примеров того, что гуй для юзеров, а кли действительно нет альтернативы (пока что, несмотря на прогресс) для более серьезных задач, очень много.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
