Комментарии 33
Странно в блоге Байкал Электроникс читать фразу:
Вообще, поддержка Arch Linux для Baikal-M нигде не заявлена, но нас это почему-то не остановило.
"Почему-то"... Ну да!
Растолкуйте, я не понимаю, чем отличие китайского ARMа и "русского" изготовленного за рубежом? это даже не КР580 местного производства, а заказ иностранцам из TSMC наподобие как в китае заказывают инструмента типа дрелек, шуруповертов, шлифмашинок итд - отличие, порой, в цвете корпуса. А как здесь? Что такого, на ARMе запускать арм -совместимых линукс?
Если взять всю схему создания чипа, то можно уложиться в 11 пунктов, и 10 из них мы делаем в России.
Вот эти 10 пунктов – сложнейшая работа, требующая невероятной точности и внимательности.
1) Разработка архитектуры системы на кристалле
2) Конфигурация всех IP
3) ВЕСЬ физический дизайн (синтез и топология)
4) Вся верификация
5) Много RTL дизайна (Register Transfer Language – описание схемотехники снк)
6) Разработка DFT (Design For Test – встроенные в RTL тестовые структуры для промышленного тестирования логики ) и Mbist (Memory Build-in Self Test – тестовые структуры внутри RTL для тестирования памяти)
7) FPGA прототипирование (Field-programmable gate array или Программируемая пользователем вентильная матрица) Нужна для целей верификации и отладки ПО на ранних стадиях проектирования.
8) Промышленное тестирование (создание ПО и тестовой оснастки для разбраковки процессоров на фабрике). Это значит, что в автоматическом режиме все процессоры проверяются на работоспособность ещё на фабрике, причём проверяются дважды – до корпусирования и после. Поэтому абсолютно все чипы, которые приезжают к нам, рабочие.
9) Разработка системного ПО и Software Development Kit
10) Bring up – первичный запуск процессора
Всего 1 500 000 человеко-часов, 3 года и 50 человек – и один процессор готов (это время, потраченное на разработку Baikal-M).
В мире 202 страны, и меньше 20 из них могут похвастаться хотя бы одним разработанным универсальным процессором.
Мы же в Baikal Electronics разработали их уже три.
Опишите полностью железо на котором запускали ОС. Где можно его приобрести ?
Так что, прочитав эту статью, вы научитесь устанавливать на Baikal не только Arch Linux, но и практически любую ОС.
*осторожно* И винду..? :)
C Windows все пока не так просто. Если очень сильно упростить картину, то любая ОС состоит из 2х частей: 1) это системный софт, который определяет что ОС из себя представляет для пользователя, и 2) ядро ОС, которое позволяет системному софту взаимодейтствовать с аппаратурой.
Что касается системного софта, то всё что умеет работать с ARM, умеет работать и с Байкал-М. Тут системный софт написанный Microsoft, в принципе, не станет исключением. Но то что касается ядра ОС, то его нужно учить работать с конкретной периферией. В компании Байкал Электроникс программисты занимаются в том числе и тем что адаптируют ядро Linux под свои аппаратные платформы. Ещё я слышал про энтузиастов которые работают над адаптацией ядра из проекта FreeBSD под Байкал-М (подробностей не знаю). А вот Microsoft пока достаточным энтузиазмом не обладает :(
Но всё что дружит с ядром Linux и ARM уже сейчас при желании установить возможно.
Я вот как раз размышляю, не купить-ли мне Rasberry Pi 4 8Gb за 9000 рублей, может лучше я куплю вот этот байкал ? Он в аналогичной малинке конфигурации стоит дешевле или сопоставимо? Понятно, что "госуха" а за оллимпиард такое купит, а жители Хабра могут его себе позволить? Если нет, нафиг сюда писать вообще?
По работе нужно. На Хабре много статей про то, что я домой точно не поставлю или не смогу себе позволить.
Ну и "отучаемся говорить про всю сеть".
Рекомендованная цена на Baikal-M - 22 500 рублей без НДС. Материнская плата с распаянным процессором, по слухам, от 30000 до 50000 рублей. Так что сильно не дешевле) Что называется - тираж имеет значение..
Достаточно один раз бегло ознакомиться с характеристиками процессоров Baikal-M и Broadcom BCM2711, который стоит в Rasberry Pi 4 8Gb за 9000 рублей, чтобы не начинать сравнивать их между собой.
Ой как 2000ыми запахло..
Скажите, а оно с cloud-init работает? Я могу просто сделать diskimage-builder, а потом получившееся dd на целевой диск, cloud-init раздел с настройками и в бой?
Вот это создаёт образ ОС из набора пакетов и виртуалку с клоном такого диска за 35с до завершения apt update на уже загрузившейся машине.
https://github.com/lidofinance/innernet-playbooks/blob/master/molecule/default/create.yml
Я не про железо, я про методологию. Размечать диск вручную с помощью gparted, реально грустно. В хорошей системе cloud-init сам всё ресайзнет, достаточно сделать dd из компактного образа.
Нет. Для gentoo элемент для diskimage-builder есть, для arch'а почему-то нет.
ну, смотрите, если мне нужно развернуть, допустим, в пяти дата-центрах по 300 виртуалок, сколько раз мне нужно запустить gparted для установки gentoo?
Все эти игрища в "администратор localhost" хороши для десктопов. В индустрии уже давно работает прагматичный подход: серверу прижигают клюв и он всю свою жизнь сидит в тесной клетке 19"x1U (некоторые в 3-4U) и кормят его через 1-2 зонда, подключаемые сзади. Нет времени церемониться со всякими "запустите, настройте". Есть типовой образ, и его надо использовать. Сам типовой образ обновляется, чтобы учесть исправления и добавления по необходимости.
Добро пожаловать в 2010ые.
ну, смотрите, если мне нужно развернуть, допустим, в пяти дата-центрах по 300 виртуалок, сколько раз мне нужно запустить gparted для установки gentoo?
Если именно виртуалки, то наверное 1 раз. Ведь вы же будете клонировать образец ВМ (и, да, с cloud-init оно работает), а не устанавливать с нуля, да? :) Если контейнеры, то 0 раз.
Но вообще, зачем вам 300 ВМ агрессивного роллинг релиза в 5 датацентрах? Для эффективного управления этим придётся и своё зеркало пакетов поднимать (чтобы на трафике не разориться), и продумывать систему обновлений и отката, делать свой "стейджинг" для пакетов и многое подобное. И если всё это сделать, то считайте что у вас свой дистрибутив и вы его сопровождаете и вам почти всё равно, кем был его папа - арчем или любым другим роллинг дистрибутивом. Так что возьмите сразу "не очень rolling" дистрибутив.
Arch прекрасная ОС, но со своим явно выраженным подходом (агрессивный роллинг дистрибутив, ориентированный на "простоту", т.е. минимизацию "лишнего" для каждого из сценариев использования), причём archlinux arm - это еще отдельные тараканы (в том числе типа того же i3 в базовом образе).
Прямо сейчас у меня есть скрипт `source rnd/activate`, который внутри использует молекулу для подъёма рабочего стенда. SUT там всего две штуки, зато остнастки и моков уже 8 штук, и это только начало. (сам git находится в study). Пик, который у меня был в предыдущем проекте - 4 сценария, каждый со своей пачкой виртуалок и некоторым количеством бареметал-серверов (которые поднимаются по тому же принципу, как виртуалки).
Разумеется, там внутри не гента, но линукс, собираемый именно diskimage-builder'ом. Алсо, сам процесс сборки и тестирования полностью автоматический (раз в неделю) и является частью продакшена.
Я к тому, что нужно очень сильно различать индустриальные методы и дескптопные. На дескптопе потратить пол-часа на возню с пакетным мендежром и настройками - нормально. В индустриальном подходе такое возможно только на этапе "придумать как". После этого всё остальное должны делать роботы, и, желательно, быстро.
Так нигде в статье и не было сказано, что "щас установим на байкал труъ продакшен способом". Железо нетипичное, выбор ОС для продакшена - нетипичный, разметка диска - нетипичная (там 3 раздела от винды, я вот тоже не понимаю зачем, но ок, пусть будет). Т. е. "продакшеном" там просто и не пахнет по постановке задачи - просто чуваки в лабе проверили, установится ли Арч, и запилили статью. Отлично, почему бы нет. Мне, например, интересен сам факт относительно типичной установки свежего дистрибутива на эту железку (хотя, надеюсь, мне это не пригодится).
Как запустить Arch Linux на Baikal-M