Решил написать небольшую заметку по настройке командной оболочки FreeBSD. В первую очередь для себя, как шпаргалку. Заметка получалась не очень большой и не такой уж интересной. Тогда попробовал объяснить, почему именно FreeBSD и вообще *BSD. Написал небольшое пояснение. И оно оказалось не про BSD. Написал ещё абзац. И снова ни слова про BSD.

«Да ёлы-палы!» — решил я и написал, как знакомился с компьютерами. Но и тут про BSD оказалось немного. Значит, судьба, решил я. Про BSD будет в другой раз. Наверное. А в этот раз опишу путь к компьютеру подростка с конца 80-х по начало 2000-х.

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

Ко мне как-то обратился коллега с вопросом: «А ты запомнил команду для подготовки архива .tar.gz?» И я такой на автомате: «tar zcf имя.tar.gz ...» А он мне в ответ: «Нет, ты не понял. Ты эту команду запомнил? Мне приходится «гуглить» каждый раз, когда требуется сделать архив.» Ах, вот в чём дело. Действительно, команду я запомнил и уже давольно давно.

Если уважаемый читать хочет узнать немного больше, то предлагаю продолжить чтение. Но хочу предупредить, что ничего ранее неизвестного и сокровенного в заметке про tar не стоит ждать (почти). Всё ещё хочется узнать подробности?

Шёл 2025 год, а я задался вопросом: «Не пора ли нашей команде выбрать стандарт языка Си, на котором будет вестись основная часть разработки?» С одной стороны кажется, что этот вопрос давно должен быть решён, стандарт языка указан в code style, конечно, после «холиваров», череды обсуждений, обид, проклятий и прочих маленьких трагедий. А если нет? А если нет, то так ли это важно? Что там нового может быть в языке Си? Стоит ли этот вопрос вообще того, чтобы тратить время? В этой заметке поделюсь с уважаемым читателем тем интересным, что я узнал и вспомнил во время неспешного исследования этого вопроса, относительно холодными и тёмными вечерами.

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

Давно начал следить за языком Rust, кажется, ещё до выхода версии 1.0. За это время язык сильно изменился, оформился и стал совсем взрослым, можно в производство. При этом из коробки программисту предлагается довольно много интересных концепций для разработки надёжного ПО с длительным жизненным циклом. Однако сфера промышленной автоматизации не так динамична (как нам иногда бы хотелось), поэтому пока приходится только присматриваться к Rust. Тем не менее надо знакомиться поближе. Просто так читать книжки или заметки не продуктивно, надо что-то пробовать делать. Например, можно начать с решения задачек на LeetCode (что я и решил попробовать). А при решении таких задачек иногда натыкаешься на что-то такое, с чем и Stack Overflow может не помочь, не только книжки. В результате поисков дополнительной информации наткнулся на серию заметок, которой хотелось бы поделиться с общественностью (да-да, он воровал тексты у богатых и переводил их бедным). Под катом перевод первой маленькой заметки про (отсутствие) NULL в Rust.

Фреймворк Qt один из самых популярных и применяемых при разработке кроссплатформенных настольных и мобильных приложений. Эта популярность не могла рано или поздно не привести к использованию Qt в системах специального и ответственного назначения. Достаточно давно существует возможность разработки на Qt для QNX Neutrino. Библиотека Qt поддерживает платформу QNX, а среда разработки Qt Creator обеспечивает взаимодействие с системами на QNX. Однако QNX, как система в том числе и для встраиваемых решений, имеет в своём составе технологии, которые не требуются, а потому и отсутствуют в системах общего назначения. Ключевая для ОСРВ QNX функциональность, на которой построена сама система и на которую нередко опираются пользовательские задачи это передача сообщений. Об особенностях применения механизма SRR (Send/Receive/Reply), как ещё называют передачу сообщений в QNX, и о разработке двух примеров Qt-приложений — клиента и сервера — я и хотел бы рассказать сегодня.

Давайте перенесёмся в 1988 год… Microsoft только что выпустила MS-DOS 4.01, а IBM начала продажи OS/2 1.1 (автор же этой заметки на Хабре лишь мечтал о БК-0010 и о таких высоких материях как операционные системы даже не задумывался). В то время ОС QNX 2 по ряду характеристик опередила других на годы. И даже теперь, более четверти века спустя, QNX 2 всё ещё работает на промышленном оборудовании, в «чистых комнатах», авионике и военной технике. На Хабре была заметка о QNX системе, которая работала 15 лет без остановки!

Поиск рабочего комплекта дискет с QNX 2 потребовал определённого времени, поиски были трудными и накладными. К счастью, мне удалось найти то, что искал. Давайте просто посмотрим, как система устанавливается на современном оборудовании под VMware Workstation.

Что такое Qnet?

• Установим Native SDK
• Настроим систему для подписывания и установки приложений
• Соберём Qt
• Создадим и настроим проект Qt-приложения