January 10th, 2009

404

Настоящие ЭВМ

Пишу статью про Урал-1.

Краткое описание: Ламповый компьютер (1000 ламп), потребляющий от 7 до 10КВт, занимающий комнату в 75 кв.м. Производительность 100 операций в секунду (числа в фиксированной запятой, 36 бит). 0.000000000001 терафлопса (если можно так сказать). Да, это не опечатка. 100 операций в секунду (при этом деление выполняется за 2 (!) такта).

Память на магнитном барабане, 4608 байт (1024 слова). Два арифметических регистра, три управляющих. У каждого регистра разная длина (от 5 до 42 бит).

Это была настоящая ЭВМ. Она ничего не знала про char. Она умела работать только с цифрами. ТОЛЬКО.

Загрузка осуществлялась с перфоленты из затемнённой киноплёнки (оригинальное решение - киноплёнка прочная, с готовой перфорацией, оборудованием для воспроизведения, массовым производством и возможностью использовать "б/у" плёнку). Скорость загрузки была 2700 бод (75 слов по 36 бит в секунду).

А теперь самое интересное - средства отладки.

На пульте были кнопки:
Ресет, стоп (пауза), старт.

Кнопка "шаг вперёд" (ЭВМ выполняла один такт). Кнопка "печать состояния" и кнопка "печать дампа памяти".
Набор тумблеров (!) для указания в двоичном виде адреса ячейки, значение которой отображалось (в двоичном виде!) лампочками.

Набор тумблеров для указания брейк-поинта.

Тумблер брейкпоинта при обращении к аппаратуре.

Мечта... Хадварная кнопка "шаг вперёд", индикация регистров... Там ещё была какая-то сложная комбинация обработчиков условного перехода...

И всего-то 10кВт. Сравните с современными 1КВт б/п...
404

О миграции в линукс

Из всего процесса (коий можно считать почти завершившимся - нерешённой осталась только проблема с равками...) я вынес для себя несколько мыслей:

0) Перед миграцией нужно попытаться найти соответствующий софт, портированный под винды. Изучение нескольких (используемых) программ в уютной обстановке сэкономит чуть-чуть нервов перед переездом (программы будут знакомы и привычны). К таковым я бы отнёс Opera/Firefox, Inkscape, GIMP (м... с натяжкой, хотя базовое редактирование изображений стоит освоить), ещё что-то, что вам нужно. При этом кривые порты (от которых больше проблем, чем удобств, вроде mc) - следует игнорировать. В родной среде они не так ужасны как в портах.

1) Миграция может происходить только (и только!) по сформулированным ТЗ. Задача "хочу так же как в windows" решается тривиальным методом: останься на windows. В то же самое время, если правильно сформулировать ТЗ, то найденное решение будет НЕ ТАКИМ как windows. Может быть оно будет хуже, может лучше. Но оно будет другим. Возможно, часть задач окажется не имеющей какого-либо смысла (и/или окажется решённой как побочный эффект решения другой задачи). Возможно, какая-то задача потребует много усилий (и даст худший результат). Но важно именно деление на ТЗ.

2) В миграции есть некая грань "гость/дома" - она определяется выполнением неких минимальных базовых вещей, без которых работа за машиной будет очень неудобна. До момента выполнения этих задач переходить на линукс чревато - вы окажитесь в условиях, когда "оно не чинится а срочно надо". Идеальным компромиссом будет дуал бут. Критические задачи допиливаются в время, когда есть желание и интерес. С момента наступления состояния "дома" надо во-первых, поумерить размах резких движений (уронить гостевую систему это не то же самое, что прихватить половину /home), во-вторых попытаться полностью освоиться. Т.е. уже не "решить ТЗ", а изучить то, чем решилось ТЗ. Вполне может быть, что функциональность решения окажется много шире исходного ТЗ (а может, часть вещей можно делать много проще). Это надо делать неторопясь, без резких телодвижений. Шоткаты, положение меню, возможности редакторов и т.д. - всё это нужно знать (я пишу с рассчётом на уровень "продвинутого виндузятника", который знает (почти) все шоткаты виндов и любимого фара/ТС). Знание этого инструментария определяет комфортность и скорость работы - а это, в свою очередь, определяет объём усилий при решении различных проблем (плохо изученный инструментарий даёт впечатление "жуткой проблемы" при тривиальных действиях).

3) Важно суметь сформулировать нерешённые проблемы (они могут оказаться уже исходного ТЗ). Чётко зная "что не так", с большой вероятностью можно будет или найти замену или перестроить рабочий процесс. Худшее, что может быть, это абстрактная мысль "да неудобно это всё" (хотя по сути вы просто не выучили хоткей или ожидаете, что сработает привычный ранее хоткей).