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/