Современные ОС и состоявшиеся специалисты

> Свелосипедь что-нибудь лучше, ты сможешь.

Может и мог бы, да не хочу и ничего не делаю для этого: мои интересы в немного другой области лежат. Да и без меня велосипедят, только щепки летят: http://www.linux.org.ru/jump-message.jsp?msgid=6043489&cid=6044266

> Да и без меня велосипедят, только щепки летят

Концепции Plan9 надо юзать не вместо, а вместе с POSIX.

> Концепции Plan9 надо юзать не вместо, а вместе с POSIX.

http://doc.cat-v.org/plan_9/translations/russian/papers/ape

Среда ANSI/POSIX, сокращенно APE, используется при необходимости портирования большого по размеру или часто-обновляемого программного обеспечения в Plan 9 или из нее. APE — это набор заголовков и объектного кода библиотек, построенных на стандарте ANSI C (ANSI X3.159-1989) и стандарте интерфейса операционных систем POSIX (IEEE 1003.1-1990, ISO 9945-1), POSIX часть описывает основные функции операционной системы. Использование APE влечет низкую скорость компиляции и выполнения кода

> Использование APE влечет низкую скорость компиляции и выполнения кода

Plan9 говно, но это не мешает использовать в Linux полезные идеи из Plan9.

Про Plan9 не знаю, но POSIX - это 100% шлак. Из-за гонок, из-за неадекватно слабых гарантий, из-за невнятных формулировок. http://lwn.net/Articles/323248/

> Жуть нах вообще хибернейтить процессы?! вот хоть пристрелите не понимаю ))))

Ну вот нужно тебе какой-то процесс временно не прибить, а приостановить. Что тогда делать?

>Жуть нах вообще хибернейтить процессы?!

Чтобы не нужно было запускать/выгружать.

Вообще, разделение на оперативную и постоянную память и необходимость постоянного запуска программ — следствие недостаточного технологического развития компов.

Глупо каждый раз при запуске программы заниматься копированием её кода из одной памяти в другую…

>Единственные ОСи, которую я бы назвал полным говном - это Win98

Для 1998-го это была великолепная ОС :)

> чудных гибридных ОС (макось и венда)

«чУдных» или «чуднЫх»?

> Хибернейт не всей машины, а процессов в отдельности.

Чем это принципиально отличается от того, что сейчас происходит с консольным процессом, если нажать Ctrl-Z, а потом набрать в консоли fg?

> У этого чувака явновыраженный недостаток ЧСВ. Даже Попов не называл свою ось вот так прямо,

В смысле? Он её называет «Фантом». Или я что-то пропустил, и переименовали?

> Для 1998-го это была великолепная ОС :)

Менеджер виртуальных машин VM86, хитро изогнутая система драйверов, адская смесь кода 16- и 32-разрядного режимов, отсутствующая система безопасности и прав доступа... — при этом оно даже умудрялось работать, вопреки здравому смыслу, который подсказывал: «не взлетит».

На великолепную ОС не тянет.

Ну вот нужно тебе какой-то процесс временно не прибить, а приостановить. Что тогда делать?

открою тебе секрет, если добавить в планировщик функцию приостановления процесса, эта задача будет решена гораздо меньшей кровью.

Чтобы не нужно было запускать/выгружать.

не ахти сколько профита

Вообще, разделение на оперативную и постоянную память и необходимость постоянного запуска программ — следствие недостаточного технологического развития компов.

Ну не столько не развитости, сколько особенности энергонезависимой памяти. Вот нету на сегодняшний день харды способной тягаться по скорости хотябы с оперативой. А между тем самая идеальная память на сегодняшний день это вообще кеш, от этого мы пока никуда не можем деться.

Глупо каждый раз при запуске программы заниматься копированием её кода из одной памяти в другую...

Даже если будут процессы хибернейтиться, код все равно придется откуда-то грузить в оперативу, почему бы тогда не грузить последний бинарник установленный в системе каждый раз, все равно что-то грузить, хоть расшибись ))))

Какой еще планировщик если мне вот прямо сейчас потребовалось какой-то левый процесс заморозить?

Какой еще планировщик если мне вот прямо сейчас потребовалось какой-то левый процесс заморозить?

ты сказал «какой-то процесс временно не прибить, а приостановить». Зачем тебе его хибернейтить с записью в постоянную память, если достаточно просто приказать планировщику не давать кванты времени процессу до востребования продолжения его работы, вот тебе приостановка процесса, реализуется в тыщу раз проще!!!

Ок. А если нужен ребут?

Ок. А если нужен ребут?

Зачем?! Я машину ребутаю только по обновлению ведра. И меня как-то не обламывает, после логина снова запустить krusader (который запомнил все свои вкладки), запустить qtcreator (тупо щелкнув в krusader по файлу проекта), щелкнуть по иконке rekonq (который тут же откроет все как и было до его закрытия). Зачем мне все это хибернейтить, один хрен после апдейта этих программ их приходится перезапускать, а ребут отнимает заметно больше времени чем запуск этих программ.

Ну я щас ядро обновляю каждые несколько дней, когда в 11.04 появляются новые сборки, плюс иногда запускаю процессы, выполняющие какие-либо громоздкие вычисление, и не допускающие ребута.

Ну вы или делайте «громоздкие вычисление» или обновляйте ведро, если мне надо собрать огромный проект например (а это кстати прекрасно переживает ребут) я почему-то не обновляю ведро. Тут или перец или сахар.

>На великолепную ОС не тянет.

В любом случае, лучше на тот момент не было. OS/2 была слишком неповоротлива и софта под неё почти не было, NT4 требовала неимоверных на тот момент ресурсов.

А тут — всё просто работало. Быстро и приемлемо надёжно :)

>Вот нету на сегодняшний день

Потому я и говорю, что следствие недостаточной технологической развитости.

А между тем самая идеальная память на сегодняшний день это вообще кеш

Кэш — это не технологический, а логический уровень. Точно также, как оперативная память, в которую грузится для исполнения программа — это кеш для HDD.

Даже если будут процессы хибернейтиться, код все равно придется откуда-то грузить в оперативу

Я же говорю, что это — проблемы технологические.

Потому я и говорю, что следствие недостаточной технологической развитости.

Может лет этак через цать, ээнергонизависимая память таки догонит, оперативку, но называть её из-за этого технологически недостаточно развитой у меня лично язык не повернется.

Кэш — это не технологический, а логический уровень. Точно также, как оперативная память, в которую грузится для исполнения программа — это кеш для HDD.

Между тем вы поняли о каком кеше я говорю и прекрасно знаете что на компы ставятся гиги оперативы лишь потому что кеш проца с аналогичными объемами стоил бы непомерно дорого.

Я же говорю, что это — проблемы технологические.

Это не проблема, а принцип работы современного компьютера. Так же я думаю вы наверно согласитесь, что идеальную программу написать впринципе не возможно и даже если сделать компьютер без «проблем технологических», программы один перец будут обновляться и процессы все равно придется прибивать и запускать по новой, чтобы юзать свежии версии ПО.

>Это не проблема, а принцип работы современного компьютера

Порождёный технологическим несовершенством :)

и даже если сделать компьютер без «проблем технологических», программы один перец будут обновляться и процессы все равно придется прибивать и запускать по новой

Естественно. Только этот процесс не будет включать в себя лишнее действие по копированию кода и ресурсов программы из одной памяти в другую :)

Естественно. Только этот процесс не будет включать в себя лишнее действие по копированию кода и ресурсов программы из одной памяти в другую :)

Вы считаете что это убивает вашь компьютер? Или это заставляет его работать существенно медленее? И да как же тогда вы будете обновлять бинарник, если его код в данный момент выполняется из той памяти куда вы его устанавливаете?! Знаете я привык, что могу сделать обновление не останавливая работу запущенных процессов, ибо свой код они держат для себя в оперативе, т.е. именно делают так вами не почитаемое копирование кода из одной памяти в другую.

Естественно. Только этот процесс не будет включать в себя лишнее действие по копированию кода и ресурсов программы из одной памяти в другую :)

Вы верите в возможность создания чего-либо технически совершенного?! Вы видите предел, где это совершенство наконец достигнуто? Давайте смотреть на жизнь реально ))))

>Win98

Потому что до Win98SE это было на редкость падучее поделие.

>И да как же тогда вы будете обновлять бинарник, если его код в данный момент выполняется из той памяти куда вы его устанавливаете?!

Посмотри, как это сейчас сделано в Windows или Linux при memory-mapping :)

Знаете я привык, что могу сделать обновление не останавливая работу запущенных процессов, ибо свой код они держат для себя в оперативе

У меня для тебя плохие новости :) Уже много лет многие программы не держат весь свой код в оперативе.

Вы верите в возможность создания чего-либо технически совершенного?!

Конечно :) Я работал с такими системами, где код исполнялся прямо с устройств долговременного хранения.

>И куда делась Win95?

95 - шикарная винда. В то время она еще не была раздутым г..ном.

>на компы ставятся гиги оперативы лишь потому что кеш проца с аналогичными объемами стоил бы непомерно дорого

почитай сперва, что было вначале, а что потом костыльно прилепили.
Кеш и не должен быть большим.

> Я работал с такими системами, где код исполнялся прямо с устройств долговременного хранения.

С перфокарт?

> почитай сперва, что было вначале, а что потом костыльно прилепили.

Почитай сперва о различиях DRAM и SRAM.

А причем тут различия? Кеш никогда не был предназначен, чтобы хранить ВООБЩЕ ВСЮ информацию.

>С перфокарт?

Пруф на машины, у которых код исполнялся прямо с перфокарт! :D

…

Хотя отчасти и ты пользуешься регулярно девайсами с исполнением с устройства хранения. Это BIOS твоего компа, например ;)

Конечно :) Я работал с такими системами, где код исполнялся прямо с устройств долговременного хранения

С перфокарт?

Хи-хи. А если серьёзно, расскажите что это было и в чем профит, может переубедити меня ибо профита вот лично я вижуть чуть более чем 0.

У меня для тебя плохие новости :) Уже много лет многие программы не держат весь свой код в оперативе.

примеры ПО шурующего свой код прямиком с харды в студию)))

BIOS твоего компа, например ;)

Мягко говоря пример не уместен, разговор о ОСях, значит программа и процесс здесь рассматриваются в разрезе их исполнения в ОС.

Смотря как им пользоватся. У меня он падал на удивление редко.

> Хотя отчасти и ты пользуешься регулярно девайсами с исполнением с устройства хранения. Это BIOS твоего компа, например ;)

Ну это очевидно.

> А причем тут различия? Кеш никогда не был предназначен, чтобы хранить ВООБЩЕ ВСЮ информацию.

Разделение на кэш и ОЗУ существует от невозможности при помощи единственного типа памяти найти оптимальный баланс по цене-объёму-времени доступа.

Разделение на кэш и ОЗУ существует от невозможности при помощи единственного типа памяти найти оптимальный баланс по цене-объёму-времени доступа.

и вот и я о том же тылдычу)))

>А если серьёзно, расскажите что это было и в чем профит

Да embedded всякий :) С перепрошивкой на лету отдельных микросхем. Микрухи прямо на память мапились, с них софт и работал.

Ещё КПК-шка была — Casio PV S450. Там аналогично. 4Мб флеша, софт мапится в адресное пространство 80186 совместимого проца и исполняется оттуда. Время на загрузку вообще не тратится. Ткнулся в приложение - оно мгновенно работает.

Насколько я помню, у Пальмов классических не было деления на оперативку и внешний носитель. Инсталлируемый софт ставился в оперативку и из неё же работал.

примеры ПО шурующего свой код прямиком с харды в студию)))

Между «исполнением кода с HDD» и «хранением всего кода в оперативке» две большие разницы :)

Да embedded всякий :) С перепрошивкой на лету отдельных микросхем. Микрухи прямо на память мапились, с них софт и работал.

embedded всегда был отдельной песней...

Между «исполнением кода с HDD» и «хранением всего кода в оперативке» две большие разницы :)

Ну да да, локации то разные HDD и оперативка :)

>Ну да да, локации то разные HDD и оперативка :)

=== cut ===
Пожалуй, наиболее общий случай, когда применяется отображение файлов на память — загрузка процесса в память (это справедливо и для Microsoft Windows и для Unix-подобных систем). После запуска процесса операционная система отображает его файл на память, для которой разрешено выполнение (атрибут executable). Большинство систем, использующих отображение файлов используют методику загрузка страницы по первому требованию, при которой файл загружается в память не целиком, а небольшими частями, размером со страницу памяти, при этом страница загружается только тогда, когда она действительно нужна.[1] В случае с исполняемыми файлами такая методика позволяет операционной системе держать в памяти только те части машинного кода, которые реально нужны для выполнения программы.
=== cut ===

// http://ru.wikipedia.org/wiki/Отображение_файла_в_память

Оно таки грузит код в оперативу, для работы процесса, не так ли? Пусть и не весь код сразу, сути это не меняет...

>Оно таки грузит код в оперативу, для работы процесса, не так ли?

Напомню, начало ветки: «Знаете я привык, что могу сделать обновление не останавливая работу запущенных процессов, ибо свой код они держат для себя в оперативе»

На что было моё возражение, что уже много лет обновляются файлы, с которых исполняется код и _не весь_ этот код обязательно лежит в оперативке.

> Насколько я помню, у Пальмов классических не было деления на оперативку и внешний носитель. Инсталлируемый софт ставился в оперативку и из неё же работал.

А данные как хранились?

Очевидно оно при затирании обновлениями хранит где-то старую версию файла до тех пор, пока все процессы не освободят ресурс, иначе за годы переодических обновлений сотнями пакетов за раз, у меня таки падали бы какие-то процессы из-за подмены источника кода. А втирал я собственно про то, что при хибернейте придется обеспечить сохранение той версии кода, которая выполнялась, соотвественно восстанавливая процесс вы будете юзать старую версию программы, или будут эпик фейлы из-за подсовывания измененых инструкций))) Мне что на сервере, что на десктопе довольно удобно каждый раз запускать новый процесс, после обновления мне не надо шаманить чтобы захибернейченные процессы перезапускались. Оно как-то происходит все само по себе, включая автоматический рестарт менеджером пакетов всех демонов, которых коснулось обновление (с учетом зависимостей, т.е. если libc был обновлен, происходит массовый рестарт демонов).

А данные как хранились?

А ни как, это порнуху ребутать было нельзя :D помню такие, ужс...

>А данные как хранились?

Там же. У классических пальмов флеша вообще не было. Т.е. были ROM или Flash для операционки и базовых приложений. Оттуда сразу и работали. И оперативка, куда ставился юзерсофт и где хранились данные.

Понятия закрытия приложения в виду однозадачности системы не было вообще. «Запуск» программы предполагал просто начало выполнения её кода, который итак всегда был доступен в адресном пространстве.

Именно оттуда идут ноги у невозможности закрытия программ на PocketPC/WM — пытались симитировать ту же фишку, но на более классической архитектуре (хотя по WM2003 юзер-софт и данные, которые не на флешке, тоже хранились в оперативке — но архитектура всё равно была ближе к классической). Внешняя имитация такого поведения сегодня в Андроиде частично воспроизводится.

Понятия закрытия приложения в виду однозадачности системы не было вообще. «Запуск» программы предполагал просто начало выполнения её кода, который итак всегда был доступен в адресном пространстве.

Это одна из причин почему пальм здох, детский сад а не архитектура.

>Очевидно оно при затирании обновлениями хранит где-то старую версию файла до тех пор

А, вроде, сайт по Linux... :)

Если ты перезаписываешь открытый файл, то он как был, так и остаётся на винте, до тех пор, пока не закроется последний хэндл. Новый файл пишется в свободное место и прописывается в каталоге с новыми inode. Старые inode по-прежнему указывают на уже недоступный по имени файл.

От этого, кстати, популярный вопрос — «я стёр файл на торрент-раздаче, а место свободное не прибавилось». Файла в каталоге нет, но он удерживается торрент-клиентом, ведущим раздачу.

А втирал я собственно про то, что при хибернейте придется обеспечить сохранение той версии кода, которая выполнялась

Всё правильно. Пока файл открыт (пусть даже гибернированной программой), он не будет удалён или изменён.

Мне что на сервере, что на десктопе довольно удобно каждый раз запускать новый процесс

И каждый раз ждать загрузки файла с HDD в RAM, его инициализации… А вот на 16-20МГц Palm'ах и Casio PV любой софт запускался мгновенно. На первом потому что он принципиально жил в оперативке и инициализировался, вообще, один раз только при первом запуска, на втором — потому что прямо из Flash исполнялся :)