Прочитав на Хабре интересную статью о VM/370, добавлю, что архитектура IBM/370 и операционная система VM/370 в частности дали многим людям возможность приобщиться к современным технологиям и архитектурам OS и “железа” лет этак на 10/20/30 (в зависимости от возраста программиста) раньше, чем эти технологии стали общедоступными для всех нас на обычных PC.

Например, еще в далеком 1972 году машины IBM/370 под управлением VM/370 имели:

• 32-битную архитектуру и мультизадачную 32-битную OS. На PC это стало доступно только через 20 лет, в 1992 году для пользователей OS/2, а массовому юзеру – вообще через 23 года, в Windows 95.
• Поддержку страничной виртуальной памяти (MMU) и подкачки. На PC такие возможности появились спустя 20 лет в OS/2. Аппаратная поддержка страничной памяти появилась на PC в 1986 году (через 14 лет после IBM/370), но операционные системы очень долго не умели ее использовать.
• 16 регистров общего назначения. На PC до этого дошли только через 31 год, в 2003 году. Большое количество регистров сильно упрощает генерацию и повышает эффективность кода.
• Аппаратную 128-битную арифметику с плавающей точкой и BCD-арифметику. На PC их нет и сейчас. :)

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

Однако до сегодняшнего дня я думал, что нужно хотя бы использовать хитрые конструкции CSS, вложенные иерархии DIV-ов и таблиц, всякие float-ы и коллапсирующиеся margin-ы, чтобы налететь на реальную ошибку.

Я был уверен, что существует хотя бы одна ситуация, когда можно не опасаться никаких засад и приколов: мы всегда можем обернуть фрагмент обычного текста обыкновенным DIV-ом (display:block; и float:none;) и быть уверенными, что наш текст останется внутри него:

<DIV>
Этот текст никогда не выйдет за пределы обычного DIV-а!
</DIV>

Но на самом деле нет пределов в этом жестоком мире браузерного маразма:

Продолжая тему предыдущего поста, прокомментирую слова tushev:

А еще интерфейс в старинной OS/2 требовал на порядки меньше ресурсов CPU и памяти.

Да, это действительно так – на порядки.

У меня нет универсального решения, и конечно я понимаю, что есть реальность, данная нам сегодня в ощущениях (исторические наслоения в виде HTML и CSS всех версий, HTTP). И очень тяжело что-либо изменить глобально. Но я хочу, чтобы каждый разработчик задумался над абсурдностью современного состояния дел в web-технологии. Иначе кардинального решения не будет ни у кого и никогда. Поэтому приведу факты, наводящие на размышления.

Пример UI 20-летней давности, который я предлагаю сначала воспроизвести всем апологетам HTML и CSS на этих языках, прежде чем минусовать «карму»:

2012 год, сайт css-tricks.com:


versus:

1992 год, стандартный элемент интерфейса OS/2:



Я убежден, что CSS и HTML – это тупиковая ветвь в развитии идеи языков разметки и пришло время отказываться от них совсем, а не улучшать их. Поэтому призываю всех серьезных программистов вообще не кодировать в них ничего напрямую и даже не использовать близкие к ним по семантике фреймворки. Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS. В результате кто-то из вас придумает мощную и кристально ясную замену этому историческому наслоению хаков.

Современная web-технология, основанная на CSS/HTML (включая даже HTML5/CSS3) – это апофеоз бессистемности в архитектуре и фрагментации. Бессистемность в начальном дизайне и последующее наложение на нее фрагментации из-за несовместимых реализаций в браузерах породили каскады хаков для латания дыр. Эти хаки (типа CSS 2.x) сами по себе уже более системные, но их разработчики связаны тем полем (HTML/CSS 1.x), на котором приходится играть. Поэтому новые версии CSS мало что решают, к тому же не полностью поддержаны в реальных браузерах.

Открыв любой серьезный CSS-файл, например, написанный в Google или FB, увидишь в нем отрицательные границы элементов, relative позиционирование через сдвиги в пикселах, огромные длины, усекаемые затем с помощью overflow: none, использование свойства content и прочие извращения. Это семантически бессмысленные и нечитаемые другими программистами конструкции. Но без подобных вещей невозможно сверстать современный веб-два-нольный сайт. Или, например, ни в одной спецификации CSS не написано, что картинка из тега <IMG>, идущая вслед за <OL> с маркером-изображением, может вклиниться визуально между маркером и текстом пунктов списка (в некоторых браузерах и при некоторых вариантах верстки).

Предлагаю следующее решение вопроса о копирайте на музыку и книги:

Законодательно запретить лейблам/издательствам заключать эксклюзивные контракты с исполнителями/авторами.

То есть попросту убрать на рынке монополию (или картельный сговор).

Навеяно предыдущей статьей на эту тему.
Для того чтобы, структурировать свое понимание – что представляют собой threads (это слово переводят на русский язык как «нити» почти везде, кроме книг по Win32 API, где его переводят как «потоки») и чем они отличаются от процессов, можно воспользоваться следующими двумя определениями:

• Thread – это виртуальный процессор, имеющий свой собственный набор регистров, аналогичных регистрам настоящего центрального процессора. Один из наиважнейших регистров у виртуального процессора, как и у реального – это индивидуальный указатель на текущую инструкцию (например, индивидуальный регистр EIP на процессорах семейства x86),
• Процесс – это в первую очередь адресное пространство. В современной архитектуре создаваемое ядром ОС посредством манипуляции страничными таблицами. И уже во вторую очередь на процесс следует смотреть как на точку привязки «ресурсов» в ОC. Если мы разбираем такой аспект, как многозадачность для того, чтобы понять суть threads, то нам не нужно в этот момент думать о «ресурсах» ОС типа файлов и к чему они привязаны.

Очень важно понять, что thread – это концептуально именно виртуальный процессор и когда мы пишем реализацию threads в ядре ОС или в user-level библиотеке, то мы решаем именно задачу «размножения» центрального процессора во многих виртуальных экземплярах, которые логически или даже физически (на SMP, SMT и multi-core CPU платформах) работают параллельно друг с другом.

В последнее время на Хабре появилось несколько постов на тему важности математики для программистов, выскажу и я свое мнение.
Не согласен с тем, что каждому программисту нужно фундаментальное математическое образование в объемах 5 университетских курсов. Оно не нужно в таком объеме большинству программистов, за исключением специалистов по вычислительным методам. Конечно же, изучение математики развивает мышление. Но есть и другие дисциплины, изучение которых развивает мышление и способствует формированию разносторонне развитой личности. Однако же, эти дисциплины не читают программистам в советских ВУЗах вообще, или читают только основы. Согласен, что математика в объемах первого курса университета (математического факультета) нужна как базис. Но учить программиста математике 5 лет именно как основной дисциплине — это неправильно.
В СССР, где были заложены принципы существующей по сей день программы обучения программистов на постсоветском пространстве, не понимали, что такое программирование и смотрели на него узко, как на специфический раздел математики. Отсюда и перекос в методике обучении программистов, когда 5 лет их учат именно математике, а собственно программированию уделяют мало внимания. Раньше программирование изучали вообще по остаточному принципу даже на программистских факультетах и специальностях (сужу по ПМПУ СПбГУ, как сейчас учат в ВУЗах я доподлинно не знаю, но вижу косвенно по уровню специалистов).

Происходит революция, примерно равная по значению появлению PC.
Благодаря Web 2.0 снова возвращается в новой реинкарнации идея мэйнфреймов. В далекие времена обработка данных происходила не на терминале пользователя (не на PC), а на центральной машине. И вот теперь снова возвращаемся к этой идее — только сейчас обработка данных происходит не на «центральной машине» в единственном числе, а на «центральных машинах» во множественном числе. Сходство становится совсем очевидным в свете последних событий. Google установила квоты на машинные ресурсы (CPU time, disk quotes) своего кластера (для приложений Google App Engine) и вскоре объявит цены за превышение квот.
«Совсем как в старые добрые? Нет, не совсем...» (С) агент Смит.