Если хочется максимизировать отношение производительности к цене, то эксперименты с маленькими/медленными SSD и выносом домашки на HDD просто не окупаются, IMHO. Проще тогда уж вложиться в быстрый HDD и добавить памяти.
Появятся, конечно. Вообще, купить SSD и продолжать держать личные файлы на HDD — это шиза какая-то. Из разряда заворачивания пультиков от ТВ в полиэтиленовые пакеты.
Ну не все так просто. В сандбоксе есть каталог, из которого можно запускать подписанные файлы, есть каталоги, в которых можно создавать файлы, но нет каталога, из которого можно запускать созданные приложением файлы:)
P.S. Про «запрещено запускать новые процессы» я неудачно выразился, конечно. Запрещено запускать именно произвольные бинарники, которых не было в бандле приложения.
Вот тут довольно подробно все описано: trailofbits.files.wordpress.com/2011/08/apple-ios-4-security-evaluation-whitepaper.pdf (глава Sandboxing, ну и Code Signing тоже).
Официальная позиция Apple — iOS-приложения не могут выполнять код, не одобренный Apple. В частности, не могут получать и компилировать код из внешних источников. Так что тут шансов мало.
С джейлбрейком, конечно, все возможно (ssh, gcc, gdb, python — все работает). Но мало кто готов вложиться в разработку качественной IDE для джейлбрейкнутых устройств, как мне кажется.
Поддерживает, конечно, много лет уже. Но это не поможет: приложениям под iOS запрещено запускать новые процессы, форкаться, модифицировать свой код или генерить нативный код «на лету» (ну то есть сгенерить-то можно, но выполнить не получится).
Да, там специализированные DSP и процессор, но они очень сложные и жрут очень много энергии. Где- то видел замечательную табличку с количествами транзисторов, но не могу найти сейчас.
Аппаратное ускорение декодирования картинок в мобильных чипах есть, в принципе. Ускоренное декодирование jpeg — чуть ли не во всех современных.
Разработчик писал на форуме, что он просто решил поизучать XNA, в результате получилось нечто играбельное, and the rest is history. А отсутствие защиты или обфускации — его сознательное решение.
Клавиши и расстояния между ними вроде бы соответствуют средней десктопной клавиатуре. Numpad-а нет, естественно, и от навигационных клавиш остались только курсорные (совмещенные с pgup/dn/home/end). Но в vim лишние клавиши и не нужны;)
Насчет мощности — 1.6 ггц i5 + 4 гигов RAM оказалось достаточно, чтобы eclipse сжевал, не подавившись, огромный проект на c++.
Планшет не рекомендую, кстати: много неожиданных проблем с софтом, очень уж это специфические устройства. Можно разве что какую-нибудь модель с «десктопной» ОС, но они обычно тяжелые.
Но я в итоге остановился на 11" ноуте (+монитор) для всего.
P.S. Про «запрещено запускать новые процессы» я неудачно выразился, конечно. Запрещено запускать именно произвольные бинарники, которых не было в бандле приложения.
Вот тут довольно подробно все описано: trailofbits.files.wordpress.com/2011/08/apple-ios-4-security-evaluation-whitepaper.pdf (глава Sandboxing, ну и Code Signing тоже).
С джейлбрейком, конечно, все возможно (ssh, gcc, gdb, python — все работает). Но мало кто готов вложиться в разработку качественной IDE для джейлбрейкнутых устройств, как мне кажется.
Аппаратное ускорение декодирования картинок в мобильных чипах есть, в принципе. Ускоренное декодирование jpeg — чуть ли не во всех современных.
Да и собственный сервер тоже ничего не гарантирует.
Насчет мощности — 1.6 ггц i5 + 4 гигов RAM оказалось достаточно, чтобы eclipse сжевал, не подавившись, огромный проект на c++.
Но я в итоге остановился на 11" ноуте (+монитор) для всего.
Я на 11" (1366*768) работаю вполне продуктивно, кстати. Иногда подключаю к внешнему 24" монитору с клавиатурой, но обычно нет необходимости.