The post has been translated automatically. Original language: Russian
In 1999, Linux was no longer just another operating system for me. After SCO Unix, there was a chance to get a similar environment on your own machine, without access to a special desktop computer and without being tied to a place where Unix was already installed.
But with freedom came another reality. The Internet was via a telephone line, the connection had to be established by dialer, the speed was low, the connection could be cut off at any moment. Downloading something big meant not clicking a button and forgetting, but really waiting for the file to finish.
The kernel sources as part of the system
Today, most Linux users never compile the kernel themselves, and there's nothing strange about that. Modern distributions already contain everything you need, the hardware is detected automatically, and updates come in ready-made packages.
In 1999, the attitude was different. The source code of the kernel was not something distant, intended only for the developers of Linux itself. You could download them, customize them for your car, and assemble them yourself.
For me, it was a continuation of the same interest that had previously led to Unix. It wasn't enough to know that the system was working. I wanted to understand what it consists of and what exactly happens between turning on the computer and the command prompt appears.
A computer for yourself
Building the kernel forced me to answer questions that users often don't see at all today. Which disk controller is in the car? What kind of network card? What file systems are needed? What can be left in the kernel and what can be omitted?
It was not an abstract learning material. If you selected it incorrectly, the system might not see the desired device or might not boot at all. Then I had to go back, change the settings, reassemble and figure out exactly what went wrong.
That's how my own computer began to understand very quickly. Not an abstract computer at all, but this particular machine — its devices, limitations, and the connection between hardware and the operating system.
Compilation was part of the training
The assembly process itself also explained a lot. You've seen thousands of source files transformed into a working system. I began to better understand where the program ends and the operating system begins, what a driver is, why header files are needed, and why the kernel cannot be perceived as one big program at all.
Of course, one cannot say that a single kernel build automatically makes a person an operating system specialist. But it destroys the feeling that there is an impenetrable wall between you and the car.
The system ceases to be something that is simply installed on a computer. It becomes a thing that can be collected.
The error was also useful.
Nowadays, many actions in computing are trying to make as safe as possible. The system warns, corrects, restores, and offers ready-made options. This is convenient and in most cases correct.
Back then, mistakes were often part of the process. An incorrectly assembled kernel, a broken driver, or an unsuccessful setup meant that you needed to understand the reason. Restoring was not just a nuisance, but another way to see the system's device.
It was these mistakes that were often remembered better than the documentation. After several hours of searching for the reason, you no longer forget why a particular parameter is needed.
The Internet was not a warehouse of ready answers
There was also a difference in the way of obtaining knowledge. Today, you can copy an error message to the search bar or ask artificial intelligence and get several solutions in a few seconds.
In 1999, everything was slower. It was necessary to search for documentation, read descriptions, understand the source code, and save useful materials locally. Even connecting to the network itself was a separate activity, so the Internet did not feel like a constantly open part of the computer.
Because of this, what had already been found and understood was more appreciated. The documentation was not a background that could be accessed at any second. It was read more carefully because the next answer might not be immediately available.
Linux has made Unix personal
SCO Unix for me was a system that I got access to at work. Linux has changed the very nature of the relationship with Unix-like systems.
Now such a system could live on its own computer. It could be installed, broken, repaired, reassembled, and studied without risking damaging the organization's work machine.
This is a very important difference. When you own a computer, you have the freedom to experiment. You can do something not because it is necessary for work, but simply because it is interesting to find out what will happen.
The source code changes the attitude of the program
When the sources are open, the program ceases to be the final subject. You can see how the decision was made, why it was implemented the way it is, where the limitations are, and what can be changed.
For a programmer, this changes the very perception of the system. You are no longer just a user of a product created by someone else. You can open his device and trace the path from the idea to the working code.
In Linux, this was felt especially strongly, because it was not about a small utility, but about the core of the operating system. What is usually perceived as the lowest and most inaccessible layer of a computer suddenly turned out to be a set of source texts that you can download and assemble yourself.
Why is everything easier now — and that's a good thing
It makes no sense to romanticize the technical difficulties of the late nineties. A slow modem did not make programming better, and the hours-long search for the right driver was not an advantage over automatic hardware detection.
Modern systems have become more convenient, and this is a huge progress. Today, a developer can get an environment in a few minutes that used to take a whole day to create.
But along with the convenience, the need to understand many of the lower levels of the system disappeared. You can write programs for years without really thinking about what's going on under the environment and libraries you're using.
What is left of this experience
For me, the main lesson was not that you have to build the core yourself. Today, in most cases, this is simply not required.
More importantly, the program and the operating system are not magic. There are always specific mechanisms, solutions, and dependencies inside. If necessary, you can go deeper into them and sort them out.
This is exactly the feeling Linux gave in the late nineties. You could start from the command line, then open the system settings, then the source code, and at some point find that the boundary between the user and the developer has become much less clear.
In 1999, I downloaded the kernel sources over a modem and compiled them for my machine. It seemed like a natural part of working with Linux back then. Now it almost looks like a story from another era, but the habit of asking the question "what's below?" I still have it.
В 1999 году Linux для меня уже был не просто ещё одной операционной системой. После SCO Unix появился шанс получить похожую среду у себя на собственной машине, без доступа к специальному рабочему компьютеру и без привязки к месту, где Unix уже был установлен.
Но вместе со свободой приходила и другая реальность. Интернет был через телефонную линию, соединение приходилось устанавливать дозвоном, скорость была маленькой, связь могла оборваться в любой момент. Скачать что-то большое означало не нажать кнопку и забыть, а действительно дождаться, пока файл дойдёт до конца.
Исходники ядра как часть системы
Сегодня большинство пользователей Linux никогда не компилируют ядро самостоятельно, и в этом нет ничего странного. Современные дистрибутивы уже содержат всё необходимое, оборудование определяется автоматически, обновления приходят готовыми пакетами.
В 1999 году отношение было другим. Исходные тексты ядра были не чем-то далёким, предназначенным только для разработчиков самого Linux. Их можно было скачать, настроить под свою машину и собрать самому.
Для меня это было продолжением того же интереса, который раньше привёл к Unix. Недостаточно было знать, что система работает. Хотелось понять, из чего она состоит и что именно происходит между включением компьютера и появлением командной строки.
Компьютер под себя
Сборка ядра заставляла отвечать на вопросы, которые сегодня пользователь часто вообще не видит. Какой контроллер диска стоит в машине? Какая сетевая карта? Какие файловые системы нужны? Что оставить в ядре, а что можно не включать?
Это был не отвлечённый учебный материал. Если выбрал неправильно, система могла не увидеть нужное устройство или вообще не загрузиться. Тогда приходилось возвращаться назад, менять настройки, собирать снова и разбираться, что именно пошло не так.
Так очень быстро начинал понимать собственный компьютер. Не абстрактный компьютер вообще, а именно эту машину — её устройства, ограничения и связь между железом и операционной системой.
Компиляция была частью обучения
Процесс сборки сам по себе тоже многое объяснял. Ты видел, как тысячи исходных файлов превращаются в работающую систему. Начинал лучше понимать, где заканчивается программа и начинается операционная система, что такое драйвер, зачем нужны заголовочные файлы и почему ядро вообще нельзя воспринимать как одну большую программу.
Конечно, нельзя сказать, что одна сборка ядра автоматически делает человека специалистом по операционным системам. Но она разрушает ощущение, что между тобой и машиной существует непроницаемая стена.
Система перестаёт быть чем-то, что просто поставили на компьютер. Она становится вещью, которую можно собрать.
Ошибка тоже была полезной
Сейчас многие действия в вычислительной технике стараются сделать максимально безопасными. Система предупреждает, исправляет, восстанавливает, предлагает готовые варианты. Это удобно и в большинстве случаев правильно.
Тогда ошибки часто были частью процесса. Неправильно собранное ядро, неработающий драйвер или неудачная настройка означали, что нужно понять причину. Восстановление было не просто неприятностью, а ещё одним способом увидеть устройство системы.
Именно такие ошибки часто запоминались лучше документации. После нескольких часов поиска причины уже не забываешь, зачем нужен тот или иной параметр.
Интернет был не складом готовых ответов
Разница была и в самом способе получения знаний. Сегодня можно скопировать сообщение об ошибке в поисковую строку или спросить искусственный интеллект и за несколько секунд получить несколько вариантов решения.
В 1999 году всё происходило медленнее. Нужно было искать документацию, читать описания, разбираться в исходниках, сохранять полезные материалы локально. Даже само подключение к сети было отдельным действием, поэтому Интернет не ощущался как постоянно открытая часть компьютера.
Из-за этого больше ценилось то, что уже удалось найти и понять. Документация не была фоном, к которому можно обратиться в любую секунду. Её читали внимательнее, потому что следующий ответ мог оказаться не сразу доступен.
Linux сделал Unix личным
SCO Unix для меня был системой, к которой я получил доступ на работе. Linux изменил сам характер отношений с Unix-подобными системами.
Теперь такая система могла жить на собственном компьютере. Её можно было устанавливать, ломать, восстанавливать, пересобирать и изучать без риска повредить рабочую машину организации.
Это очень важное различие. Когда компьютер принадлежит тебе, появляется свобода эксперимента. Можно сделать что-то не потому, что это необходимо для работы, а просто потому, что интересно узнать, что получится.
Исходный код меняет отношение к программе
Когда исходники открыты, программа перестаёт быть окончательным предметом. Ты можешь увидеть, как принято решение, почему реализовано именно так, где находятся ограничения и что можно изменить.
Для программиста это меняет само восприятие системы. Ты уже не только пользователь продукта, созданного кем-то другим. Ты можешь открыть его устройство и проследить путь от идеи до работающего кода.
В Linux это ощущалось особенно сильно, потому что речь шла не о небольшой утилите, а о ядре операционной системы. То, что обычно воспринимается как самый нижний и недоступный слой компьютера, вдруг оказывалось набором исходных текстов, которые можно скачать и собрать самостоятельно.
Почему сейчас всё проще — и это хорошо
Нет смысла романтизировать технические трудности конца девяностых. Медленный модем не делал программирование лучше, а многочасовой поиск нужного драйвера не был преимуществом перед автоматическим определением оборудования.
Современные системы стали удобнее, и это огромный прогресс. Сегодня разработчик может за несколько минут получить среду, на создание которой раньше уходил целый день.
Но вместе с удобством исчезла необходимость понимать многие нижние уровни системы. Можно годами писать программы, почти не задумываясь о том, что происходит под используемой средой и библиотеками.
Что из этого опыта осталось
Для меня главный урок был не в том, что ядро обязательно нужно собирать самостоятельно. Сегодня в большинстве случаев это просто не требуется.
Важнее другое: программа и операционная система не являются магией. Внутри всегда есть конкретные механизмы, решения и зависимости. Если нужно, в них можно спуститься глубже и разобраться.
Именно это ощущение давал Linux конца девяностых. Ты мог начать с командной строки, затем открыть настройки системы, потом исходный код и в какой-то момент обнаружить, что граница между пользователем и разработчиком стала гораздо менее чёткой.
В 1999 году я скачивал исходники ядра по модему и компилировал их под свою машину. Тогда это казалось естественной частью работы с Linux. Сейчас это выглядит почти как история из другой эпохи, но привычка задавать вопрос «а что находится уровнем ниже?» у меня осталась.
Share
