Re: Утилиты в стиле true unix way
Hello!
On Monday 11 January 2010 01:09:17 Oleg Tsymaenko wrote:
> кстати а как вы согласуете всё это с "UNIX way"
Мы уже давно обсуждаем user way, а отнюдь не unix. Ну как можно говорить о "правильном" десктопе,
если пользователь ориентируется критериями вида "хочу", "нравится" и т.п.?
Имхо - для десктопа заниматься софтом не вижу смысла - скоро пользователям будет достаточно
браузера для получения всех "хотелок", а необходимая функциональность будет реализована на стороне
сервера (без разницы, запущенном непосредственно на этом десктопе или на удаленном хосте) так, как
это удобно разработчикам. С этой точки зрения, нужен плугин для монтирования носителей в
файрфоксе, благо javascript API для управления локальными файлами уже есть.
Например, у меня близкие mail-клиента знают только в виде веб-интерфейса, общаются в каких-то там
социальных сетях тоже через браузер и т.п. Джаббер, кстати, для них уже неактуален - последние месяцы
сообщения шлют в почту - пора ставить веб-клиента и для джаббера.
Касаемо исходной темы топика - наблюдаю определенное непонимание. В частности, весьма активно
обсуждается использование PostgreSQL на замену MySQL, не замечая того, что уже сегодня их архитектура не
оправдывает себя - попробуйте получить "приличный" результат от постгреса на 8-ми ядерном сервере
с парой sata-винтов в зеркале. Уже есть ssd-диски, но пока их производительность (и цену) до ума доведут,
в десктопах будет десяток-другой ядер. С PostgreSQL и SQLite - разница в производительности в
реальных приложениях достигает нескольких порядков величины. Для веб-приложений, где количество
операций чтения на один-два порядка превосходит число модифицирующих, пострес в тестах и
продакшене оказывается просто нонсенсом. А при ста ядрах и почти таких же дисках?.. Разумеется,
у SQLite есть свои проблемы - но эти проблемы технического характера, а не принципиального, в отличие от.
Для повышения конкурентности можно блокировать лишь область файла, а не весь файл, можно обеспечить
доступ на чтение к модифицируемой БД и т.п. Равно как использование in-memory базы с периодическим
ее дампом на диск позволяет и сейчас получить высокую конкурентность (собственно, мускул на серверах
пожалуй чаще гробит дисковую базу, чем требуется перезапуск и дамп in-memory базы). Есть и другие
СУБД, в том числе без поддержки SQL и проч. - так они еще намного быстрее. О них особо не упоминаю, т.к.
для сотен или тысяч запросов в секунду достаточно SQLite (а много вы знаете проектов, обрабатывающих
десятки или сотни тысяч ежесекундных запросов на одном хосте?).
Или возьмем веб-сервер - случается, что эффективнее на каждый запрос запускать процесс-обработчик,
отдавая задачу ОС, нежели доверять это веб-серверу. Как пример - на одном ядре процессора CoreQuad в
секунду можно выполнить около 7000 запусков генератора листинга директорий. Притом на более сложных
задачах накладные расходы на запуск дополнительных процессов стремительно снижаются. А посмотрите
"типичные" форумы, которые сжирают все ресурсы сервера при паре запросов в секунду... Зато мускуль,
апач, все как "у взрослых" ;-) - и ресурсы потребляются непрерывно, даже при полном отсутствии нагрузки.
Более того, вполне реально, что через пару-тройку лет линуксовое ядро будет "рулить" процессами не
хуже, чем сейчас это реализовано, скажем, в эрланге. А программеры будут по-прежнему громоздить
MySQL, apache, etc.
Хм, вероятно, что флейм начнется, дернуло же меня подробно ответить на ваш кратенький вопрос :-)
А впрочем, несколько интересных ответов я уже получил, есть над чем подумать и что попробовать.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Reply to: