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

В публикации - три короткие "живые" истории. Первая про старое железо и 6-битные байты. Вторая про старый софт и Министерство Обороны. И третья про старые баги и новые айФоны.

Наверное, мне не дано понять всю красоту и мощь диаграмм Ганта. Зато попытки разобраться в них подарили открытие — деятельность Кароля Адамецкого, человека, который не просто опередил и Ганта, и своё время, но придумал менеджмент, каким мы его знаем, когда абстрактное управление проектами идёт параллельно с работой с людьми.

К сожалению, все его разработки конца 19 — начала 20 века были известны в пределах Российской империи, и тогда по большому счёту не до менеджмента было. Поэтому первенство в открытии проектных диаграмм осталось за Гантом, а первые попытки описать менеджмент как современную дисциплину стали достижением Тэйлора. А Адамецкий вошёл в историю почти никому не известным гением. Дальше — просто его история, интересные находки и озарения.

Введение

По мере изменения климата волны жары становятся все более интенсивными: они длятся дольше, идут чаще, а температуры всё выше. Сейчас одна такая волна проносится через Европу: в Испании и Португалии только за прошедшую неделю умерли 1100 человек. Люди просто оказались не готовы к температурам выше 35 ºС: у них в домах не было кондиционеров, а многие днем выходили и пытались работать как обычно. И получили огромные проблемы со здоровьем.

В целом по Европе за одно это лето счет идет уже на десятки тысяч. Этот год, по всей видимости, станет даже более смертоносным, чем печально известный 2003-й, когда в Европе от жары погибло 30 000 людей. Но тогда температура доходила до 37 ºС, сейчас — под тем же Парижем фиксируют уже до +42 ºС.

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

Попытаемся ответить.

Конкурентность сложно как следует наладить, как минимум, тем из нас, кому не повезло писать на языках, непосредственно открывающих нутро конкурентного аппаратного обеспечения: речь о потоках и разделяемой памяти. Не менее сложно организовать конкурентность так, чтобы она работала и правильно, и быстро. Все, что вы знаете об оптимизации однопоточного кода, зачастую вам не поможет. На микроуровне (отдельные инструкции) просто невозможно применить обычные правила, актуальные для μ-операций, цепочек зависимостей, пределов пропускной способности и т.д. При конкурентности правила другие.

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

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

Часто ловлю себя на мысли, что рассуждаю именно в таких категориях, когда мне нужна высокопроизводительная конкурентность: каков наилучший уровень, который я реально могу достичь при решении конкретной задачи? Держать в уме эти уровни полезно и на этапе первичного проектирования (иногда небольшое изменение требований или высокоуровневого дизайна позволяют вам выйти на более выгодный уровень), а также при оценке уже существующих систем (для еще более точного понимания имеющейся производительности и выстраивания пути наименьшего сопротивления, ведущего к улучшениям).

23 июля 2021 года на «Хабре» прошло как-то спокойно, никто даже и не вспомнил, что в этот день во всем мире отмечали шестидесятилетие пишущей машинки «IBM Selectric І». Вдумчивый читатель спросит: а что, теперь надо отмечать юбилей каждой модели пишущей машинки, которая была выпущена за всю историю человечества? Сразу же отвечу: нет, всех не надо. А вот особо выдающихся — надо. Тем более, что «IBM Selectric І» — это не просто очередная пишущая машинка, а целый компьютер, который смогли создать и запустить в массовое производство в конце 1950-ых годов.

Весело, конечно, но «полотно» состоит в основном из выводов команд. Если честно, гораздо интереснее прочитать не только про саму установку системы, но и про её «кишки», как, что, да почему.
Исследовать исходники VM/370, к примеру.

Автор Лысый Камрад (@LKamrad)

Диск Сабу (инвентарный номер JE 71295) можно увидеть в Каирском музее под стеклом витрины в комнате №43. Ему более пяти тысяч лет, и он найден в гробнице "принца Сабу", недалеко от ступенчатой пирамиды фараона Джосера, но сам артефакт, как минимум, на два-три века старше этой самой древней египетской пирамиды.

Глядя на него, становится до какой-то степени понятен энтузиазм сторонников альтернативной истории и палеокосмического контакта - настолько необычно смотрится этот артефакт.

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

У невероятного роста Youtube есть одно последствие, радостное и грустное одновременно - множество историй потеряются под слоями новой краски. Именно поэтому я хочу рассказать одну из них - историю того, как 10 лет назад маленькая команда веб-разработчиков задумала убить IE6 с помощью Youtube и даже не получила за это по шапке.

Я не могу вспомнить то конкретное событие, из-за которого наша команда разработки начала строить планы убийства браузера за обедом в столовой Youtube. Возможно, в тот раз я случайно отправил в релиз CSS-стиль, где был указан селектор атрибута на нестандартном HTML-элементе. Любой здравомыслящий веб-разработчик предположил бы, что если браузер не может распознать элемент - он молча пропустит данное описание. Но со старыми версиями IE дело обстояло не так. В определенных условиях это приводило либо к внутренней рекурсии и падению браузера (если повезет), или даже к синему экрану смерти (если не повезет).

А может быть, в сотый раз кто-то из наших разработчиков использовал тег <img> без указания атрибута src. От новичков никто не требовал быть в курсе, что в старых версиях IE вместо пустого аттрибута src подставляется корневой путь ("/"). Это внезапно превращает тег <img> в <iframe>, загружая главную страницу и все связанные с ней ресурсы, что может привести к бесконечной рекурсии. Когда пустой тег <img> случайно просачивался на главную страницу - вся команда в экстренном режиме искала его, пока сервера не расплавились под нагрузкой.

В общем, не вдаваясь в подробности - это была настоящая жесть, и она была связана с IE6. Этот браузер сильно отравлял жизнь всей нашей команде разработки. По меньшей мере 1-2 недели из каждого мажорного релиза отводились на то, чтобы заставить новый UI работать под IE6. Несмотря на всю эту боль, нас заставляли поддерживать его ради пользователей, которые не могут обновиться или работают в компаниях, где обновление запрещено политиками безопасности. Пользователи IE6 на тот момент составляли примерно 18% от общего числа. Все понимали, что просто так прекратить его поддержку нельзя, но когда мы сидели в той столовой после нескольких бессонных ночей, на сопереживание тем несчастным пользователям просто не оставалось сил. Мы начали коллективно фантазировать о том, как отомстить IE6. Одна идея сразу привлекла всеобщее внимание: а что, если мы просто пригрозим прекратить поддержку? Как отреагируют пользователи? Они поднимут бунт против Youtube, начнут присылать нам письма с угрозами расправы (как это уже случалось раньше)? Или вдруг станут апологетами новых браузеров? Мы мечтали о том, как офисные работники по всему миру внезапно начнут придумывать причины, по которым обновление браузеров жизненно необходимо для бизнеса, а бабушки и дедушки возьмут своих технически прошаренных внуков в заложники, чтобы те "починили им ютубы". То, что началось как сеанс групповой психотерапии, стало превращаться в конкретный план действий, для реализации которого у нас были уникальные условия.

Критическая уязвимость в Java, в библиотеке log4j, которая используется в тысячах сервисов, начиная от Minecraft и заканчивая Apple Cloud, быстро превращается в серьезную угрозу для организаций по всему миру. Уязвимости подвержены сервера Apple, Valve, Microsoft и других.

Язык Си - один из наиболее влиятельных языков программирования за всю историю. Он стал незаменимым инструментом разработки операционных систем, сместив с этого пьедестала языки ассемблера. Изучение Си обязательно для любого уважающего себя программиста. Этот язык любим за свою внешнюю простоту и ненавидим за беспощадность к ошибкам. Благодаря нему у нас есть ядро Linux и тысячи уязвимостей в нём же в придачу.

Попробуем понять, что же такое этот противоречивый язык Си - благословение или проклятие?

В этой статье я собрал обобщающую информацию по некоторым программным эмуляторам советских компьютерных систем - начиная от больших ЭВМ типа БЭСМ-6 и заканчивая микропроцессорными электронными играми.

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

Несколько месяцев назад одна из крупнейших онлайн бирж IP-адресов выступила с заявлением, что в первом квартале 2021 года цены на адреса протокола IPv4 достигли исторического пика и превысили 32$ за адрес. Судя по всему, на данный момент цены продолжают расти, доходя до 60$ за адрес и выше.

В этой статье я постараюсь объяснить, почему адреса IPv4 стали столь дорогостоящим и востребованным активом, можно ли получить их в собственность, какими правами обладают их держатели, как их приобрести и не потерять.

1. фронтенд, преобразующий исходный код в промежуточное представление
2. конвейер машинно-независимой оптимизации (IR): последовательность проходов, которые переписывают IR для устранения неэффективных участков и структур, которые не могут быть непосредственно преобразованы в машинный код. Иногда эту часть называют middle-end.
3. Машинно-зависимый бэкенд для генерации ассемблерного кода или машинного кода.

По работе мне часто приходится рисовать разные схемы, диаграммы процессов и графики, в том числе и те, которые потом используются в качестве иллюстраций для сайта, статей и презентаций. Всё бы ничего, но есть у диаграмм и графиков, сделанных в популярных онлайн-сервисах наподобие draw.io или lucidcharts одна беда — они выглядят как-то слишком уныло и «олдскульно», в духе «90-х». Всю эту инфографику хотелось бы сделать более заметной, привлекательной и душевной (и, желательно, без привлечения дизайнера).

Так у меня возникла идея создания инструмента для отрисовки диаграмм и графиков в стиле «нарисовано от руки». Об истории создания сервиса и «подводных камнях» я расскажу в этой заметке.

Здравствуйте, меня зовут Дмитрий Карловский и раньше я тоже использовал Perl для разработки фронтенда. Только гляньте, каким лаконичным кодом можно распарсить, например, имейл:

/^(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,})|("(?:((?:(?:([\u{1}-\u{8}\u{b}\u{c}\u{e}-\u{1f}\u{21}\u{23}-\u{5b}\u{5d}-\u{7f}])|(\\[\u{1}-\u{9}\u{b}\u{c}\u{e}-\u{7f}]))){0,}))"))@(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,}))$/gsu

Тут, правда, закралось несколько ошибок. Ну ничего, пофиксим в следующем релизе!