Средства и методы разработки

Пост третий из стапиццот. PIF -- не костыль! Вопреки тенденции написания невообразимого ПО, которое для сжигания Рима прожига дисков таскает с собой целый цирк с оркестром и кордебалетом, нормальные программы всё-таки выполняют одну функцию. Этим очень хвастаются адепты опенсорса (хотя это не так, особенно на системном уровне -- то есть на том, на котором соблюдение этого принципа было бы очень нужно), и совсем не хвастаются разработчики коммерческого ПО (хотя это так). К счастью, на прикладном уровне более-менее картина пристойная у всех. Вот именно эта пристойная картина и позволяет к каждому приложению цеплять конфиг, в котором прописывать те вещи, которые для данного железа являются специфичными. Игра-аркада, попав на электронную книжку, потребует частичного быстрого обновления дисплея. Текстовый редактор -- частичного при скроллинге окна и при печати, полного -- в определённые моменты, такие, как активная работа приложения с диском (допустим, врубилось автосохранение) и перерисовка области окна, равной всему окну. Просмотрщик изображений -- полного обновления дисплея. К счастью, тут у нас развязаны руки. Это не АПИ, взаимодействует с этими настройками пользователь, поэтому у нас развязаны руки лепить любые вычурные параметры, обусловленные нашей лютой фантазией при портировании ОС на данное железо. Например, DVD-плеер на x86 с не-писишной периферией может нести на себе Нашу Воображаемую ОС, чтобы быть не чисто плеером, а более-менее ноутбуком. Жаль только, что, скажем, Firefox быстро убьёт нам SSD, свопаясь на него, ибо не приучен к хорошим манерам... но мы, портируя ОС, держим в голове то, что SSD для нашей платформы не совсем типичен. Следовательно, порт с усиленной поддержкой SSD может запрещать определённой программе использовать своп. А теперь удар прямо в мозг. Отмапим, имея 2 гб оперативки, рядом с ней в то же пространство 64 гб флэшки, чтобы исполнять код прямо оттуда. Предвосхитите проблему и решите её при помощи прицепленной системной конфиги. * * * пауза на размышления * * * Операционка, естественно, приучена не выгружаться просто так из памяти. Это естественно, она же в нашей власти. Следовательно, нам не обязательно стопать её при отключении устройства. Аналогично, процессы тоже снимать не обязательно, достаточно скинуть содержимое оперативки, которое когда-либо было выдано им при аллокации (и только его), в свободное место на флэшке, а при включении -- скинуть обратно. Процессы свято уверены, что не было никакого отключения. Проблема же в том, что некоторые программы могут пожелать модифицировать те данные, что лежат прямо посреди кода, или даже отполиморфить сам свой код. Это сразу даст нам огромные тормоза на записи во флэшку и её адский износ. 99.9% программ этого не делают, а если даже и полиморфят себя -- то в специально зааллокаченной области, которую им система выдаст, очевидно, в реальной оперативке. Остальным .1% мы просто пропишем свойство "загружать в реальную RAM". А если их не стесняться ещё и выгружать оттуда при отключении, в отличие от загруженных во флэшку -- эта же галка на автомате решает проблему тех программ, которым жизненно необходима реалтаймовость и "разрыв времени" при отключении устройства сносит им мозг. Они просто будут сняты, как обычные проги при обычном выключении, и не будут "радовать глаз" зависанием и потенциально опасными глюками. Темп замедляется, посмотрим, когда будет продолжение и о чём оно будет. Думаю переходить уже к процу и системам команд, проблематика которых и породила этот джава-рак.