True Unix GUI, Unix, Операційні системи, статті

Віктор Вагнер

Останнім часом багато шуму лунає навколо ідеї про вступ Linux (і взагалі Unix-подібних систем) у війну за місце на ринку настільних систем. Як розвідки боєм у цій війні виникли і розвиваються такі системи, як KDE та GNOME. Але, на мою думку, ці системи приречені на провал. Я не вважаю, що Linux не місце на десктопі користувача. Просто атакувати позиції Windows треба з іншого флангу.

Що таке KDE та GNOME – це всього лише спроба побудувати над ядром Unix і X-Window систему, засновану на тих же принципах, що і Windows – документ-орієнтована модель, взаємодія між додатками на базі drag’n’drop і Object Request Broker, купа непотрібного прикрашення. Фактично для такої системи всі переваги нижележащей багатозадачною, розрахованої на багато, прозоро інтегрованої в мережу системи стають недоліками, що приводять тільки до непотрібного витраті ресурсів. Ресурсів зараз, як правило надлишок, але це ж не привід тринькати їх без користі.

В результаті, ми отримуємо монстра, в якому робота з віддаленими ресурсами обмежена лазіння по Web, можливостей розширення – не більше ніж у Windows. Добре хоч компілятор безкоштовний, але ж і в Windows його вже портанулі, а так для написання мінімальної примочки до потрібно писати на C, або у випадку KDE на C + +.

Користувач цієї системи знову віддається на милість програмістам – він може користуватися тільки тим що для нього написали, оскільки вивчати C і, тим більше писати на ньому, у нього немає часу. У нього свої, користувальницькі, завдання – отчетік красивий сваять, порахувати небудь.

Зауважимо, що і програмісти в наш час, у всякому разі те переважна більшість їх, яке обслуговує завдання бізнес-користувачів, користується для розробки усілякими системами Rapid Application Development, тобто по відношенню до самого Desktop Environment виступають скоріше як користувачі, ніж як програмісти. У той же час ні KDE ні GNOME не починалися з ідеї – давайте напишемо RAD-середовище, в якому можна зробити все. Що, до речі, сильно обмежує і кількість їх розробників, і продуктивність кожного з них.

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

Порівняємо це з ситуацією на початку 70-х років – епохи переможної ходи Unix по університетах США. Чому ця система змогла тоді витіснити набагато більш “дружні до користувача” LISP-машини?

На мій погляд тому, що вона послідовно проводила одну нехитру ідею – “не хочеш спілкуватися з програмою сам – примусь це робити іншу програму “. Я впевнений, що на цьому місці кожен з читачів згадав щось типу ls-l | grep root або find. -Name “*. Bak” | xargs rm. Так, мова саме про ці конструкціях.

Основна їх перевага полягає в тому що вони, по-перше, цілком доступні користувачеві, який вміє працювати в командному рядку, а по-друге є повноцінними програмами на мові shell. Їх можна записати в файл, оголосити цей файл виконуваним і користуватися поряд з іншими командами системи.

Якщо згадати, що звіти в ті часи писали на troff, який вельми підходить для обробки sed-ом і awk, то виявиться що користувачі цілком могли легко адаптувати систему до своїх потреб. Причому цей процес швидше нагадував навчання – зробив щось один раз, дав цій операції ім’я, і ​​далі вимагаєш зробити операцію з таким-то назвою.

Результатом цього стало практично повна відсутність бар’єру між використанням системи і програмуванням в ній. І подальший розвиток в общем-то не привело до його збільшення. У відповідь на X-Window з’явився Tk, у відповідь на інтерактивні програми типу ftp – expect.

Інша справа що практично незмінним залишився бар’єр між людиною, бачить комп’ютер в перший раз і кваліфікованим користувачем, в зняття якого досягли успіху інші системи, особливо MacOS.

Пам’ятником тому славному часу служить O’Reilly-вкая книжка “sed & awk “, яка фактично є літописом верстки серії про X window.

Які ж складові інтерфейсу командного рядка Unix, які виявилися в свій час настільки вдалі, що живуть вже 30 років, і до сих пір знаходиться чимало людей, що віддають перевагу їх різноманітним GUI?
На мій погляд їх чотири:

Очевидно, що модель обробки даних, заснована на цих чотирьох китах, не покриває потреб сучасного користувача.

Найбільш слабким місцем виявляється текстовий файл як універсальний спосіб подання інформації в поєднанні з регулярними виразами для його обробки. По-перше, крім тексту є зображення і звук. По-друге, оперувати з текстом на рівні символів не завжди зручно – хочеться опереіровать на рівні пропозицій, абзаців, а то і глав. По-третє, існують табличні дані, які не завжди зручно обробляти в awk – Іноді потрібен sql. По-четверте, є елементи оформлення – шрифти, накреслення і пр., які іноді несуть істотну тематичну навантаження. (Тут ми вступаємо на театр військових дій між прихильниками логічної і фізичної розмітки, до боротьби між якими ми ще повернемося).

Іншим слабким місцем є регулярні вирази, як вбудований в систему спосіб розпізнавання образів. Вони по-перше, складні для користувача – недарма AltaVista ними не користується, по-друге дуже обмежені за своїми возможнотсям – переставте місцями два слова і все.

Є обмеження і у концепції перепризначення вводу-виводу. Вона принципово лінійна, хоча простір на екрані принципово двумерно. Мені дуже часто хочеться написати щось на зразок

 gzcat / var / log / httpd / access.log.gz | tee v | grep одне
                                       | + -> Grep інше

У командному рядку так не можна. Хоча з боку ядра Unix принципових заперечень немає. Інша справа що намагаючись записати це з яким завгодно синтаксисом на другому-третьому рівні вкладеності обов’язково заплутаєшся. А якщо не писати, а малювати на екрані мишкою стрілочки? Тоді можна охопити поглядом досить складну схему потоків даних. З ветвеленіямі, злиттям і багато чим ще.

Відволікаючись трохи від теми: А чи не здається вам, що час графічних інтерфейсів як таких закінчується? Гряде час інтерфейсів голосових, які, як не дивно куди ближче до командної рядку Unix, ніж до графічного інтерфейсу Windows. Адже мова лінійна, і буде належним чином розпізнана, перетворюється в той самий потік текстової інформації, який так люблять традиційні утиліти Unix. Що ж до синтезу мови, то це завдання просто вже вирішена – берете festival і перепризначає висновок на нього. Буде потрібно, правда трохи змінити синтаксис shell’а і, особливо, регулярних виразів, щоб команди було зручно вимовляти, а видачу – сприймати на слух.

Але голосове введення – поки ще туманне майбутнє. Найближчі роки два-три нам доведеться жити з мишкою, віконцями та іконками, яким до речі, приблизно стільки ж років, що і Unix.

Отже, яким же повинен бути істинно юніксячій графічний інтерфейс?