[room] Давайте покурим на тему DE vs WM

[Денис Смирнов]

On Fri, Jan 22, 2010 at 11:01:13AM +0400, Денис Черносов wrote:

ДЧ> Ну сейчас таки фич побольше (plug`n`play, drag`n`drop hot plug и много
ДЧ> других страшных слов). 

Из этих страшных слов в OS/2 не было разве что только plug'n'play.

А drag'n'drop там гораздо более развитый чем в современной винде был. В
смысле того насколько во многих местах он был предусмотрен и работал.

ДЧ> И спектр оборудования, на котором _должно_
ДЧ> работать тоже существенно побольше. 

Это не проблема DE, уж извини, а проблема ядра и драйверов. Кстати, в
конце 90-х IBM купила skytech (та самая, что делала либы, которые еще
первые игрушки под DOS с крутой графикой использовали для работы с
видюхой). И поэтому были чудесные драйвера -- которые просто молча при
старте системе детектили видюху, и все работало.

А по поводу дисковой подсистемы -- Daniela Engert (если не ошибся с
написанием имени) написала также чудесный драйвер danis506.sys. Который
точно также детектил IDE-контроллер, и поэтому bus master DMA mode на тех
связках контроллер/HDD где он должен был работать -- просто работал. Из
коробки. Без гемора с настройкой (в винде тех времен нужно было ставить
отдельные драйвера, да еще и вручную включать bus mastering галочкой --
ибо не было гарантии что заведется).

ДЧ> И очень много обвязок, связанных с
ДЧ> безопасность (проверка всяческих буферов на переполнение и т.п.), что
ДЧ> не может не добавлять тормозов.

Опять же, с точки зрения security -- еще _до_ изобретения NX-bit в
процессоре, в OS/2 аналогичная функция была и работала. Напомиаю, речь
идет о системе 15-и летней давности. И, кстати, в ней объем виртуальной
памяти у 32-х битного приложения не ограничивался ни 2Gb, ни 4Gb :)

Сделано это было красивым хаком -- пользуясь тем, что 386-й (как и все
современные процы, кстати) умел _и_ страничную, _и_ сегментную адресацию.

Те кто помнят времена DOS, те помнят такой термин как "модель памяти". В
нынешних OS используется страничная адресация и flat модель памяти -- по
сути аналог того, что во времена DOS называлось small модель памяти. Т.е.
использование исключительно указателя смещения, без указателя сегмента.

В OS/2 была доступна модель памяти, которая аналогична 'large' модели
памяти. Т.е. приложение могло состоять из нескольких сегментов -- данные,
код. Каждого из которых могло быть _несколько_. Таким образом данные
лежали в сегменте данных, а код -- в сегменте кода. И как ни старайся,
выполнить данные нельзя.

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

Напоминаю -- мы сейчас говорим о системе устаревшей 15 лет назад, просто
написаной с умом.

ДЧ> Печаль в том, что жизненный цикл и железок и ПО страшно мал. А потому
ДЧ> ваш знакомый во многом прав, сермяжной жизненной правдой. Что толку
ДЧ> делать автомобиль, который прокатается 50 лет, если через три года он
ДЧ> морально устареет?

При написании коммерческого ПО это вполне разумно. Я заказчику часто
объясняю, что вон ту хрень я могу написать за несколько дней (и она
потребует сервер за 5k$) или за полгода (и она запуститься даже на
микроконтроллере). Но моя работа за эти полгода будет стоить куда больше
сервера. Очевидно, что именно выбирает заказчик :)

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

ДЧ> Потенциальное светлое место в этой безнадеге, как ни странно, DE.
ДЧ> Точнее, лежащие в их основе фреймворки. Потому что их могут отлаживать
ДЧ> и оптимизировать отдельные немногочисленные специалисты, а результаты
ДЧ> оптимизации будут положительно влиять на всю систему в целом и на
ДЧ> каждое приложение в отдельности.

Ты это... не путай DE и тулкиты. Я ничего не имею против, например, Qt.
Или каких-либо других библиотек.

А вот против DE в их нынешнем виде -- имею. И своими глазами вижу, как эти
DE становятся монструознее, без существенных изменений в функциональности.
А количество глюков растет. Разве что compiz появился -- и то хорошо.

ДЧ> Второе светлое направление: маломощная техника, у которой во главу
ДЧ> угла поставлена энергоэффективность. Там оптимизация всегда будет
ДЧ> приветствоваться, а жесткие рамки системы опять же будут раздвигаться
ДЧ> очень неохотно. И такой техники вокруг нас становится всё больше. Ждем
ДЧ> обратной миграции заоптимизированного кода с нетбуков и смартфонов на
ДЧ> десктопы и мэйнфреймы... :)

Да, это оказалось очень полезным для ядра. А то какую активность начинает
Nokia с Qt в мобилках -- тоже на пользу.

Только вот незадача -- на мобилках нет ни KDE, ни Gnome. Поэтому такие DE
так и останутся тормозами глючными.

ДЧ> З.Ы. А вот еще подумалось, что корректнее сравнивать тот древний 386-й
ДЧ> с современным айфоном и андроидом. По параметрам. И там всё не так уж
ДЧ> мрачно, как вы описываете...

Некорректно. 386-й -- дебильный процессор с CISC-архитектурой, без
математического сопроцессора (а у меня была именно такая модель), с
мизерным объемом кэша по современным меркам (а он там вообще был?), и
40Mhz, и хард у меня был на 210Mb. IDE, разумеется, с несколькими
мегабайтами в секунду при чтении и, разумеется, обычным для HDD медленным
seektime.

А вот тебе HTC Hero:
- 512Mb ROM (в два раза больше чем мой старый _HDD_)
- 288Mb RAM (почти в 20 раз больше чем на той 386)
- дисплей 320x480 -- на той 386 был 640x480. Правда 256 color
  (соответственно HTC Hero не надо тратить ресурсы процессора на
  dithering)
- microSD -- мжно прицепить флешку. Т.е. еще один "хард". Все современные
  флешки в разы или даже более чем на порядок объемнее и быстрее чем мой старый
  хард (в комплекте 2Gb)
- RISC-процессор 528MHz. Т.е. тактовая частота почти в 15 раз больше чем
  на той 386-й.

Дополнительно в этой мобилке есть:
- 3D ускоритель
- аппаратные кодеки для H.263, H.264, MPEG-4 и еще кучи всего
- и куча всего еще интересного

Мне только кажется, или речь идет практически уже не о мобилке, а о том
что 15 лет назад назвали высокопроизводительной рабочей станцией для
научных рассчетов и для военных, с ценой в несколько десятков тысяч
долларов (и размерами как минимум с хорошую тумбочку)?

А стараниями шибко умных программистов получилась звонилка с mp3-плеером.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------