Замечание по ведению журнала

[vitus_wagner]

Если еще кто-то когда-то в моем журнале будет упоминать в положительном контексте что-либо, сделанное в рамках GNOME и KDE, буду банить как за мат.

Comments

[alamar.livejournal.com]

"Вот когда они свои проприетарные патчи отдадут в upstream"
FAIL

Fault tolerance мне вот лично по барабану: kpdf у меня не падал, akregator у меня не падал, amarok у меня падает раз в полгода. У меня железо чаще глючит. Меня интересует функциональность; с твоим подходом ее не будет, зато ее отсутствие будет хорошо обосновано. А то я не знаю.

[vitus_wagner]

А потом эти люди, у которых "оно не падало", рассказывают что для работы в Linux необходимо не менее 2Гб и 4ГГц, да еще и жалуются что приложения плохо используют мультикоровость.

А я удивляюсь про что это они - у меня все работает &tm; на 96Мб PII-233 или 400Mhz ARM/128Мб.

Проблема еще и в том, что функциональности в КДЕ/ГНОМЕ, на мой взгляд, нет. Когда это надо руками делать и глазами смотреть, это не функциональность. Функциональность это когда один раз посмотрел глазами и сделал руками, второй раз, а на третий преодолел лень, написал три строчки и дальше оно само.

[alamar.livejournal.com]

У меня последние полтора года Athlon XP 2ГГц с 1 гигабайтом памяти. Отлично работает, большая часть памяти свободна.
До этого несколько лет был Athlon простой на 1.2 ГГц, 256 мегабайт памяти, всё отлично работало, память свободная оставалась.

Прекращай уже жечь, а?

[nine_k]

Тут немного путаются подходы. Когда "написал три строчки и дальше оно само", да ещё с fault tolerance — это мир деевелоперский. Такие люди на свой телефон по ssh ходят. Это хорошо и удобно, но они в меньшинстве.

"Обычный юзер" толком написать три строчки, как правило, умеет только на естественном языке. Для него компьютер — инструмент, наподобие автомобиля: надо, чтобы он ехал с минимальными когнитивными усилиями, хоть и не нулевыми. "Обычный юзер" — не глупый человек, просто он специалист в другом, не в компьютерах.

Соответственно, с выходом линукса на массовую аудиторию open source-разработчики срочно пытаются как-то сделать удобно обычному пользователю. Но, не будучи специалистами во всяком UI и usability, делают, как получается: внутренне неоптимально, не слишком логично, архитектурно неуклюже. Вы их за это, соотвественно, ругаете.

Грубо говоря, в FOSS хватает людей, умеющих писать код. Для этого есть масса инструментов, понятия наработаны. А для разработки взаимодействия с юзером всего этого, imho, практически нет. Непонятно, что взять, чтобы поиграться с интеграцией GUI-компонентов, да и где взять эти компоненты в подходящем виде — более того, непонятно, какой вид для них вообще подходящий.

Это всё давно известно, конечно. Но что с этим делать, по-преднему непонятно.

[vitus_wagner]

Ну если написать три строчки юзер может только на естественном языке, значит нужно писать интерпретатор естественного языка.

Потому что любой инструмент, и софт в том числе может пользователя либо порабощать, либо освобождать. Третьего не дано. Инструмент порабощает, когда он сужает горизонты, ограничивает кругозор и заставляет человека выполнять тупую механическую работу по обслуживанию инструмента, не задумываясь о том, ЗАЧЕМ нужен вообще-то этот инструмент (или ограничиваясь утверждением "за это деньги платят").

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

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

Но тем не менее, это освобождение, возможность собственного выбора пути.

[nine_k]

Совершенно согласен с мыслью, что инструмент должен освобождать. Просто я, как всегда, об интерфейсах.

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

А то был бы интерфейс системного конфигурирования наподобие Scratch :)

[vitus_wagner]

Подозреваю, что надо эксплуатировать систему "глаз-рука", как более древнюю и хорошо отработанную %)

И кончится это тем, что офисный планктон будет вытеснен обезьянами, как более дешевыми в эксплуатации.

[nine_k]

Ну, может быть: есть пограничная область задач, которая компь.терам пока не совсем по зубам, а высшим приматам поддаётся :)

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

Возможно, в этой области лежит некоторое число решений, которые позволят простым пользователям™ лучше пользоваться гибкостью, заложенной в софт. Интерфейс ведь не обязан быть непременно тривиальным; преимущество GUI — discoverability и соотв. более низкий порог вхождения. При этом я не считаю нынешние мэйнстримные WIMP-интерфейсы слишком адекватными, разумеется. Опять сравню с играми.

А те, кто начнёт этим же софтом пользоваться совсем профессионально, освоят я написание команд, просто потому, что это быстрее :) Но им будет легче, потому что уже будет понятие, из каких доступных управлению кусочков софт состоит.

[diseaz.livejournal.com]

Сколько видел игр, ничего сложного они не предоставляют. Через три дня любая "навороченная" современная игра становится банально скучной, т.к. 95% времени уходит на чисто утилитарные действия, которые можно было бы описать формально, чтобы машина делала их за тебя и позволила бы сосредоточиться на том, что пристало человеку, а не на однообразном кликании. В результате, выигрывает тот, кто быстрее кликает и может удержать в голове то, чего он хочет добиться и вагон утилитарных действий, которые просто надо сделать. Это относится и ко всяким RPG, и RTS и к пошаговым стратегиям. В онлайн-играх даже специально запрещают скриптинг. Если бы интерфейс был достаточно богат, его бы не понадобилось (по крайней мере так сильно), либо скриптинг не давал бы такого выигрыша, а при нынешних интерфейсах скриптинг позволяет избавиться от этих самых 95% рутины, которые, с его запретом, пользователи вынуждены выполнять сами.

Командный интерфейс, при этом, совсем не отменяет discoverability. Как пример -- расширение ubiquity для Firefox. Офигительные, действительно контекстные подсказки без лишних телодвижений. Если еще расширить это возможностью класть типовые команды на Link Bar, как bookmarklet... К сожалению, подобного интерфейса для повседневной работы, на замену Unix shell, я что-то не видел, но это не означает, что такое невозможно.

Кстати, из разговора с одним из экспертов по User eXperience почерпнул интересное знание о культурных различиях пользователей. Западные пользователи, как правило, умеют работать с клавиатурой, поэтому они нормально относятся к вводу текстовых команд (особенно, если есть подсказка, вроде ubiquity). Российский простой пользователь™ набирает текст одним пальцем, поэтому ему легче десять раз мышкой кликнуть, чем три буквы набрать. У восточных народностей с набором текстов тоже не сахар (~50 тыс. иероглифов, поди), даже для тех, кто вполне бегло строчит по клавишам. Отсталым вообще проще в тачскрин пальцем тыкать, ибо по земляному полу даже мышку нормально не покатаешь.

[dmitry-vk.livejournal.com]

>akregator у меня не падал

akregator — жутко падучая вещь. Да и еще и использует свою лисапедную metakit вместо кошерного sqlite, вследствие чего постоянно падает и теряет данные.

[alamar.livejournal.com]

Ни разу не падал. 1.2.19. Debian lenny.
Данные вроде не терял. Пару раз странно терял непрочитанность на нескольких статьях, я так и не понял, почему.

SQL сосёт, так что их можно понять.

[dmitry-vk.livejournal.com]

Вам везет :)
Либо metakit не любит x86-64. Либо что-то еще. Но факты остаются фактами. На двух моих машинах падает.
SQL sucks, но что в этом мире не sucks? Хоть SQL и sucks, но «настоящие» субд, по крайней мере, данных своих не теряют.

[alamar.livejournal.com]

А в какие моменты падает-то?