Таким образом, благодаря своей унифицированной организации ввода-вывода Система 360 способна выполнить загрузку с любого ВУ, реализующего команду «основное чтение»
В курилках даже вели дискуссии на тему возможности начальной загрузки с устройства системной консоли или с некоторых моделей дисплеев. Формально, в них тоже была реализована эта команда.
В некоторых случаях УВУ и ВУ технически являются одним целым и для пользователя неразличимы; к таким устройствам относятся, например, принтеры, устройства ввода и вывода перфокарт и т. д.
Не ради придирки, а для уточнения: были модели УВУ, которые технически исполнялись отдельными устройствами и объединяли в себе управление принтерами и перфокарточным вводом-выводом, оставляя за самими ВУ исключительно механические функции. К таким относилась, к примеру, IBM 2821 - название ЕС-овского аналога я привести не могу, но сам видел такие УВУ "в железе" на ЕС-1022. Программно такие УВУ, похоже, были неразличимы, но при генерации ядра ОС их требовалось указывать - очевидно, чтобы учитывать специфику загрузки ввода-вывода при одновременной работе.
Довольно сложно понять, зачем в сверхцентрализованном СССР распыляли силы на решение разными организациями одних и тех же задач, но что было, то было.
Централизация была не такой уж "сверх": были, к примеру, и ведомственные поликлиники, и ведомственные детсады, и ведомственное жильё, и ведомственные дома отдыха. В данном случае, очевидно, получилась ведомственная система вычислительной техники - вся серия АСВТ, а затем сменившая её СМ, предназначалась для нужд автоматизации производства.
Поначалу Кеплер пытался объяснить результаты наблюдений Тихо Браге, построив свою теорию из "классических" вложенных сфер. Он с сожалением писал, что был вынужден отказаться от "красивых" окружностей и перейти к "уродливым" эллипсам только потому, что они давали намного более точные соответствия наблюдениям.
Отмечу ещё одну особенность Фортрана на IBM/360, и не только. Вследствие очень простых соглашений о связях было удобно компоновать в одной программе подпрограммы на Фортране и на ассемблере. Например, Colossal Cave Adventure и Super Star Trek были написаны на Фортране, а подпрограммы обмена с дисплеем для них - на ассемблере.
Это традиции такие. В прошлом веке технологии продавали Советскому Союзу - причем изначально военные технологии, к примеру, танки и авиамоторы. И ни о каких реформах тогда речи не шло.
Тут, правда, есть один нюанс: чтобы использовать заменители ХФУ, требуется платить патентные отчисления. Мне кажется, сумма этих отчислений давно уже перекрыла затраты на финансирование всех тех наблюдений, исследований и подготовки договоренностей.
Догнать-то мог, корабль позволял, но для этого потребовалось бы отцепить весь металлолом, который был на буксире, и увеличить расход топлива, что прямо противоречило требованиям работодателя.
Но сам рассказ Пиркса, скорее, похож красивую "охотничью байку". Поиск старых ракет наверняка был, и обстановка на борту могла быть взята из жизни, и рой метеоритов мог встретиться, а вот всё остальное, сдается мне, он придумал от скуки за эти два месяца полёта без тяги.
Хорошо забытое старое. Когда-то, когда компьютеры были мэйнфреймами, они не покупались, а брались в аренду. В этом была и хорошая сторона: платили за время, пока считаются задачи пользователя, а пока чинили железо, арендная плата не начислялась.
В этом "если" и есть весь смысл. Базы со штрих-кодами могут (а значит, будут) объединяться, в т.ч. с использованием других ШК переменной длины. Длина "эталонного" ШК - соответственно, ведущие нули в нем - важная информация, терять которую нельзя.
Пример: ШК 0780201379623 (EAN-13) может соответствовать одному товару, а 780201379623 (Code-128 или Code-39) - другому.
В числах ведущие нули не имеют значения, а в штрих-кодах они несут определенную смысловую нагрузку. То есть вместе с такими числами должна храниться/передаваться информация про то, что для сравнения со строкой ШК из нужно преобразовать с ведущими нулями. Лучше хранить сразу строку.
Суть в том, что начиная с некоторого порогового значения теплового импульса понятие "горючее" существенно расширяется. К примеру, алюминий и железо горят очень даже неплохо. Я уже не говорю про асфальт.
Что касается объединения гонений в единый мощный костер - к сожалению, это уже было проверено на практике - в Гамбурге, Дрездене и других городах. К слову, некоторые исходные данные для расчетов по "ядерной зиме" были взяты как раз оттуда.
Авторы концепции "ядерной зимы" отдельно разбирают вопрос, чем горение в условиях огненного шторма должно отличаться от обычных пожаров. В частности, предполагается, что сажи будет выделяться в разы больше.
Насколько я помню авторские публикации о "ядерной зиме" (в журналах "Наука и жизнь" и "В мире науки" - перевод "Scientific American"), там разъясняли ещё два предполагаемых обстоятельства.
Во-первых, в зоне огненного шторма возникнет самоподдерживающееся горение с мощным притоком воздуха извне. Температура в центре повысится до такой степени, что гореть начнут не только дерево и асфальт - будут гореть металлы и бетон, так что "топлива" и в современном городе предостаточно.
Во-вторых, возникнет мощный восходящий поток, который закинет сажу и прочие мелкодисперсные частицы аж в стратосферу, откуда они уже не смогут вымываться осадками, а будут постепенно оседать.
По приведенным подсчётам, энергия взрывов и последующих пожаров будет сравнима с энергией обычных процессов в земной атмосфере. Соответственно, какое-то влияние на атмосферу однозначно ожидается, но вот будет ли оно настолько катастрофичным - вплоть до перестройки глобальных атмосферных циркуляций, исчезновения тропопаузы и возникновения сверхустойчивости - проверять на практике как-то совсем не хочется.
В курилках даже вели дискуссии на тему возможности начальной загрузки с устройства системной консоли или с некоторых моделей дисплеев. Формально, в них тоже была реализована эта команда.
Не ради придирки, а для уточнения: были модели УВУ, которые технически исполнялись отдельными устройствами и объединяли в себе управление принтерами и перфокарточным вводом-выводом, оставляя за самими ВУ исключительно механические функции. К таким относилась, к примеру, IBM 2821 - название ЕС-овского аналога я привести не могу, но сам видел такие УВУ "в железе" на ЕС-1022. Программно такие УВУ, похоже, были неразличимы, но при генерации ядра ОС их требовалось указывать - очевидно, чтобы учитывать специфику загрузки ввода-вывода при одновременной работе.
Моё предложение такое: внутри ведомственных "владений" правили бал люди с производства, которым важнее был результат "здесь и сейчас".
Централизация была не такой уж "сверх": были, к примеру, и ведомственные поликлиники, и ведомственные детсады, и ведомственное жильё, и ведомственные дома отдыха. В данном случае, очевидно, получилась ведомственная система вычислительной техники - вся серия АСВТ, а затем сменившая её СМ, предназначалась для нужд автоматизации производства.
Перевод "редактор" - отголосок более древних времён, когда в оригинале он назывался linkage editor.
Поначалу Кеплер пытался объяснить результаты наблюдений Тихо Браге, построив свою теорию из "классических" вложенных сфер. Он с сожалением писал, что был вынужден отказаться от "красивых" окружностей и перейти к "уродливым" эллипсам только потому, что они давали намного более точные соответствия наблюдениям.
Отмечу ещё одну особенность Фортрана на IBM/360, и не только. Вследствие очень простых соглашений о связях было удобно компоновать в одной программе подпрограммы на Фортране и на ассемблере. Например, Colossal Cave Adventure и Super Star Trek были написаны на Фортране, а подпрограммы обмена с дисплеем для них - на ассемблере.
Это традиции такие. В прошлом веке технологии продавали Советскому Союзу - причем изначально военные технологии, к примеру, танки и авиамоторы. И ни о каких реформах тогда речи не шло.
Тут, правда, есть один нюанс: чтобы использовать заменители ХФУ, требуется платить патентные отчисления. Мне кажется, сумма этих отчислений давно уже перекрыла затраты на финансирование всех тех наблюдений, исследований и подготовки договоренностей.
Догнать-то мог, корабль позволял, но для этого потребовалось бы отцепить весь металлолом, который был на буксире, и увеличить расход топлива, что прямо противоречило требованиям работодателя.
Но сам рассказ Пиркса, скорее, похож красивую "охотничью байку". Поиск старых ракет наверняка был, и обстановка на борту могла быть взята из жизни, и рой метеоритов мог встретиться, а вот всё остальное, сдается мне, он придумал от скуки за эти два месяца полёта без тяги.
Хорошо забытое старое. Когда-то, когда компьютеры были мэйнфреймами, они не покупались, а брались в аренду. В этом была и хорошая сторона: платили за время, пока считаются задачи пользователя, а пока чинили железо, арендная плата не начислялась.
В этом "если" и есть весь смысл. Базы со штрих-кодами могут (а значит, будут) объединяться, в т.ч. с использованием других ШК переменной длины. Длина "эталонного" ШК - соответственно, ведущие нули в нем - важная информация, терять которую нельзя.
Пример: ШК 0780201379623 (EAN-13) может соответствовать одному товару, а 780201379623 (Code-128 или Code-39) - другому.
В числах ведущие нули не имеют значения, а в штрих-кодах они несут определенную смысловую нагрузку. То есть вместе с такими числами должна храниться/передаваться информация про то, что для сравнения со строкой ШК из нужно преобразовать с ведущими нулями. Лучше хранить сразу строку.
Выравнивание. Ну то есть на некоторых процессорах прочитать по байтам можно, а целиком как int - получим прерывание.
Я встречал следующее: если у нас есть адрес первого из 4-х подряд идущих байтов, мы можем прочитать их как 32-разрядный int
Спасибо!
Было бы здорово ещё составить список заблуждений о штрих-кодах. Из того, что известно мне: EAN-13 можно хранить в виде числа.
Когда-то здесь, на Хабре, публиковался перевод доклада Римского клуба. На мой взгляд, эта статья в чём-то с ним перекликается, чем-то дополняет.
Суть в том, что начиная с некоторого порогового значения теплового импульса понятие "горючее" существенно расширяется. К примеру, алюминий и железо горят очень даже неплохо. Я уже не говорю про асфальт.
Что касается объединения гонений в единый мощный костер - к сожалению, это уже было проверено на практике - в Гамбурге, Дрездене и других городах. К слову, некоторые исходные данные для расчетов по "ядерной зиме" были взяты как раз оттуда.
Авторы концепции "ядерной зимы" отдельно разбирают вопрос, чем горение в условиях огненного шторма должно отличаться от обычных пожаров. В частности, предполагается, что сажи будет выделяться в разы больше.
Насколько я помню авторские публикации о "ядерной зиме" (в журналах "Наука и жизнь" и "В мире науки" - перевод "Scientific American"), там разъясняли ещё два предполагаемых обстоятельства.
Во-первых, в зоне огненного шторма возникнет самоподдерживающееся горение с мощным притоком воздуха извне. Температура в центре повысится до такой степени, что гореть начнут не только дерево и асфальт - будут гореть металлы и бетон, так что "топлива" и в современном городе предостаточно.
Во-вторых, возникнет мощный восходящий поток, который закинет сажу и прочие мелкодисперсные частицы аж в стратосферу, откуда они уже не смогут вымываться осадками, а будут постепенно оседать.
По приведенным подсчётам, энергия взрывов и последующих пожаров будет сравнима с энергией обычных процессов в земной атмосфере. Соответственно, какое-то влияние на атмосферу однозначно ожидается, но вот будет ли оно настолько катастрофичным - вплоть до перестройки глобальных атмосферных циркуляций, исчезновения тропопаузы и возникновения сверхустойчивости - проверять на практике как-то совсем не хочется.