Нет, это не замена из-за отсутствия многозадачности. Это механизм для получения информации от десятков программ, не держа их в фоне. Пуши хорошо экономят заряд батареи и процессорное время. Хороший пример — IRC клиент вынужден сидеть в фоне в течение всего дня и парсить протокол, что на больших каналах будет неплохо сказываться на ресурсах. Хотя требуется лишь уведомлять пользователя о приватных сообщениях или хайлайтах в общем чате.
И да, с появлением многозадачности в iPhone пуши никуда не исчезнут. Не смотря на то, что программа будет висеть в фоне, скорее всего она будет отсоединяться от сети и переходить на пуши через определенное время после входа в бэкграунд.
Навскидку — такие задачи обычно решаются способом динамического программирования. То есть решается сначала для n первых элементов массива в нашем случае, потом для n+1 и так далее. Эдакая рекурсия наоборот. Сложность будет для вышеприведенной задачи O(n^2). Хуже чем в простейшем алгоритме, описанном выше (с помощью сортировки), но встречаются задачки, которые решаются с хорошей асимптотикой этим методом. Например, определение соответствия шаблону, заданному с использованием wildcard'ов.
Согласно SDK перед уходом в background программа должна высвободить часть ресурсов и закрыть сокеты. И на дальнейшую работу в фоне накладываются некоторые ограничения, касающиеся изменений окон и т. д. Причём программа всё-таки может выполнять часть работы, правда процессорного времени будет выделяться сильно меньше. Но программа может попросить систему выделить ей нужное кол-во ресурсов за счёт использования специального API, которое реализует несколько пунктов, про которые сказал Стив, т.е. audio, voip, geo-location и прочие.
Это в общем-то самое главное. Никакого гибернейта нет. Программа будет жить в памяти и по приходу того же пуша для аськи сможет восстановиться гораздо быстрее (скорее всего моментально) ведь все элементы интерфейса остаются в ram.
Apache тоже можно собрать нестандартный. В Debian так возможно, потому что нет бинарных компонентов, в случае OS X пользователь не может перекомпилировать компоненты системы под новые билиотеки. Но кстати, улучшенная поддержка модулей и компонентов для apache в Leopard Server это интересная идея.
Такой возможности нет. Но можно рассмотреть идею и реализовать. Пользователь не хочет, чтобы сайты генерировали иконки сами по себе, поэтому возможно надо сделать, чтобы работало как шорткат для вызова окошка, где можно отредактировать название и ссылку.
MacPorts поддерживается Apple'ом, как и XQuartz, x11.app поставляется в комплекте с системой. Возможно, что он будет включен в основной набор. Однако, я не совсем понимаю, если вы говорите о тех проблемах с разными версиями библиотек, то тут нет какого-то универсального метода решения, так как многим библиотекам Mac OS X потребуются именно те версии ПО, которые поставляются. Как я уже говорил, MacPorts не пишет поверх системного ПО, поэтому достаточно подставлять нужные значения env переменных в определенных случаях, и всё будет хорошо.
Да, именно к этому всё и идёт. Но пока не решен вопрос о том, какой язык использовать для ядра (ObjC или Ruby). У нас коммитеры делятся на ярых противников tcl и на ярых противников скриптовых языков :-)
Одна из основных причин, препятствующих развитию MacPorts — tcl. Из-за того, что язык не самый приятный, разработчики сторонятся проекта. Были попытки переписать/реализовать часть функциональности на Objective C или Ruby, но узкое место — portfiles. Портфайлы написаны на tcl, и без tcl-прослойки их прочитать или сконвертировать не так-то просто.
Проблема частично решается правильной установкой переменных DYLD_LIBRARY_PATH, LD_LIBRARY_PATH и других. В настоящее время мы работаем над новой системой контроля зависимостей, более гибкой и удобной, чем в настоящий момент.
www.pixlr.com заметно подтомаживает, а мой ноутбук начинает взлет, только что проверял. Он, конечно, немного сложнее, слои поддерживает, поэтому сравнение может быть необъективным.
Именно, говоря об «открытости» Flash Apple сравнивает его с WebKit и парой других своих похожих проектов. OpenSource сообщество сильно улучшило движок. Мне кажется, что рано или поздно, по мере появления технологий, перетягивающих на себя одеяло (как в случае html5 для видео), Adobe придёт к тому же. Ситуация будет как в случае IE — вчера, монополисты, сегодня наверстываем упущенное.
И да, с появлением многозадачности в iPhone пуши никуда не исчезнут. Не смотря на то, что программа будет висеть в фоне, скорее всего она будет отсоединяться от сети и переходить на пуши через определенное время после входа в бэкграунд.
Это в общем-то самое главное. Никакого гибернейта нет. Программа будет жить в памяти и по приходу того же пуша для аськи сможет восстановиться гораздо быстрее (скорее всего моментально) ведь все элементы интерфейса остаются в ram.