Почему в Linux невозможно использовать SJF (Сначала самое короткое задание )?
Вы можете использовать следующее для установки текущих версий всех пакетов PHP, предоставляемыхphp-defaults:
apt install $(grep-aptavail -S php-defaults -s Package -n)
(Сначала необходимо установить dctrl-tools.)
Здесь используются две команды:
grep-aptavail -S php-defaults -s Package -n
ищет пакеты, о которых aptзнает, ищет исходный пакет (-S), соответствующий «php -defaults», и выводит список соответствующих бинарных пакетов(-s Package)без имени поля(-n); результат используется через подстановку команд в качестве аргументов для
apt install
который устанавливает пакеты.
Это установит версию PHP по умолчанию и все расширения, предоставляемые PHP, и обеспечит их обновление по мере того, как новые версии станут стандартными (, поэтому при обновлении с Debian 9 до Debian 10 и PHP 7.3 станет по умолчанию вместо PHP 7.0 все ваши расширения PHP 7.0 будут обновлены до версии 7.3 ). Однако вам нужно будет повторно -запустить команду, чтобы подобрать новые расширения и очистить устаревшие отдельно.
Вы можете адаптировать это для установки каждого пакета, который зависит от php-common, что приведет к всем доступным расширениям PHP, но в результате будет установлено гораздо больше пакетов, чем имеет смысл.
Навскидку, я мог бы придумать ряд причин, по которым Самая короткая работа в первую очередь является полным запретом -в любой общей -системе назначения.
Первая проблема кроется прямо в названии: вам нужно заранее определить «кратчайшее» задание. lsв локальном каталоге, вероятно, довольно короткий, но время выполнения, например. процесс оболочки может занять от долей секунды (для короткого сценария )до недель или месяцев (для моей интерактивной оболочки ). ОС не может этого знать, а во многих случаях и сама утилита. Не говоря уже о том, что обычно требуется множество интерактивных утилит, которые могут работать одновременно. (Кроме того, насколько я понимаю, SJF в базовой форме не является -упреждающим, со всеми вытекающими отсюда проблемами.)
Конечно, если вы разделите понятие «задания» на меньшую единицу, чем весь процесс, это может быть немного полезнее. Но это не совсем соответствует концепции процессов как они есть, процесс не может сигнализировать о начале нового «задания». Даже если бы они были, вам все равно нужно знать, какова продолжительность работы. Вы могли бы доверять сообщению о процессе, но в многопользовательской -системе это вызвало бы некоторую несправедливость. Или вам нужно было бы иметь некоторые проверки, чтобы убедиться, что объявленная длина задания соответствует реальной продолжительности задания, но теперь это начинает звучать как настоящий планировщик операционной системы...
Дело не в том, что подобные концепции не использовались. Насколько я помню, в планировщиках Linux есть функции, которые пытаются отличить интерактивные процессы (от тех, которые простаивают в течение длительного времени, но затем выполняют короткую работу, которая должна иметь высокий приоритет ). и не -интерактивные (, которые работают с более стабильной скоростью ).