LINUX.ORG.RU
ФорумTalks

Почему Линукс устарел?

 


0

0

Начнем с самого святого — ядра. Оно монолитное, этим все сказано. Для встраиваемой техники это, безусловно, может быть полезным, но для ПК это выливается в отсутствие гибкости и стабильности. Если в монолитном ядре произойдет сбой — конец. Ядра же с современными архитектурами умеют просто выгрузить сбойный модуль и спокойно продолжить работу.

Далее, в чисто монолитном ядре не предусмотрена подгрузка и выгрузка модулей, что вынуждает перекомпилировать его каждый раз при изменении состава оборудования, откуда и растет мем «конпеляция ведра». Естественно, это не удобно, и разработчики Линукса пошли на шаг, превративший ядро в полный НЁХ: они с помощью костылей добавили подобный функционал. Что вышло? Мы имеем все преимущества и недостатки модульной архитектуры одновременно с недостатками монолитной. А почему у монолита не осталось преимуществ? Они все были нивелированы переходом к модульности. И все равно, как ни странно, все сходятся во мнении, что ядро Линукса по прежнему монолитное со всеми его «достоинствами».

Вторая часть проблемы, создаваемой монолитом — сложность. Сам Торвальдс уже говорит, всё настолько плохо, что для исправления бага в ядре приходится искать человека, разбирающегося в соответствующей части. И зачастую это тот человек, что её писал. А некоторые личности в обсуждении успешно «осваивают» ядро.

Безусловно, после этих слов им можно верить. А ведь Эндрю Таненбаум предупреждал Торвальдса, что ОС с монолитной архитектурой ядра будет гигантским скачком в прошлый век. Едем дальше. Что у нас? О, это же концепции UNIX, положенные в основы Линукса. Ни у кого после этого не повернется язык сказать, что ЛИнукс — современная ОС.

Убогий «всё есть файл», когда придумали более совершенный «всё есть объект»,текстовый ввод-вывод(понимаете, какой это ****?),настройка ОС текстовыми файлами и упор на консольные приложения.

О последнем подробнее. Множество линуксоидов считают консоль удобным интерфейсом(ага, в 21 веке то), но основные приводимые доводы оказываются надуманными от невозможности это доказать не на чувственном уровне. Основные причины любви стоит выделить две: 1)Консоль — главная часть хакерского стереотипа, а поскольку хакером сегодня быть круто и модно, то на бессознательном уровне вырабатывается любовь к черному окну, зелененьким буковкам и непонятным для непосвященных действиям. 2) Мнение, что если разработчики делают консольных программ больше, чем графических, то это круто и должно быть удобно, вот не знаю, но ведь это всё не зря… По правде, это сказывается неоднородность самого Линукса. Пользователю, может, удобно иметь кучу нескучных обоин и DE, но для разработчика просто ад делать свою программу одновременно рабочей для KDE, GNOME и прочих сред. Поэтому он выбирает то, что работает во всех Линуксах одинаково — консоль. Вот и весь секрет: разрабатывать консольные приложения удобно, но это не значит, что их удобно использовать. А всё остальное высосано из пальца. Иксы. Старая вещь, появившаяся еще до рождения Линукса. Гордость каждого линуксоида. И это притом, что их сейчас мечтают заменить чем-то менее прогнившим и более быстрым, но все никак не могут. Вообще, об этом звере из деревянных шестеренок на костылево-скипидарном приводе стоит писать отдельную статью. Пользователи последней убунты сами могут почувствовать, насколько быстрые иксы, запустив htop и поседев от ужаса, наблюдая за показателями ЦП в полном бездействии. Может, вам пофиг, а если у меня ноутбук? Жалко батарейку.

Снова едем дальше. Вы никогда не думали, почему пользоваетей Линукса так мало и почему они с ужасом оббегают Линукс стороной? А потому что не всех устраивает качество и количество софта на него. А почему? А потому что разработчики с ужасом оббегают Линукс стороной. А почему? Вот мы и подошли к главному. Нет, проблемы, описанные выше играют свою роль, но есть что-то по мощнее. Скажите, удобно ли разработчику поддерживать свой продукт для 300+ несовместимых дистрибутивов? А еще на каждом может быть по 10 вариаций DE, получая уже 300*10. А разные наборы разных версий библиотек? Dependency hell? Тоже. Последнее вообще стало отдельным мемом

Отсюда приходим к дальнейшим проблемам: Линукс не только устаревает, но еще и отстает. Хороший пример — недавнее добавление поддержки PCI-E 2.0, в 2012 году,когда все нормальные люди пользовались этим уже в 2008. А ведь во всю бушует PCI-E 3.0 и анонсирован 4.0. Правильно, зачем нам скорость в 16 GT/s, когда есть 5 GT/s? И такое повсюду: когда у всех что-то считается устаревшим, в Линуксе оно только появляется. Никому не хочется писать нормальный софт, потому что и писать то нормально не выйдет, что уж там работать ему, в итоге это ложится на плечи самым упоротым энтузиастам.

★★★

Последнее исправление: hakavlad (всего исправлений: 2)
Ответ на: комментарий от WitcherGeralt

Если ты даже этого не понимаешь

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

hakavlad ★★★
() автор топика
Ответ на: комментарий от WitcherGeralt

Уж всяко проще нажать Ctrl+R и ввести пару буков, чем надрачивать секунд по 20 у гуях, чтобы сделать то же самое.

В GUI можно вызывать команды парой нажатий горячих клавиш, которые подписаны в самом GUI и легко запоминаются по мере надобности. Ещё в GUI часто делают поиск команд как в Ctrl+R.

X512 ★★★★★
()
Ответ на: комментарий от X512

В GUI можно вызывать команды парой нажатий горячих клавиш

Давай, нажми мне «пару клавиш»:

$ history | wc -l
8839

Ещё в GUI часто делают поиск команд как в Ctrl+R.

Какой ужас! Хватит это терпеть!

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Хватит это терпеть!

Жириновский покусал?

X512 ★★★★★
()
Ответ на: комментарий от X512

Тебе написать парочку команд, чтобы ты обосрался со своими горячими клавишами и поиском в гуях, пытаясь повторить?

WitcherGeralt ★★
()
Ответ на: комментарий от X512

И, кстати, важная деталь: одна единственная консоль, где есть всё и сразу, против хреновой тучи гуёвых приложений на каждый чих, единый текстовый интерфейс против гуёвых неожиданностей, автодополнение против необходимости запоминать набор из сотен горячих сочетаний.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

И, кстати, важная деталь: одна единственная консоль, где есть всё и сразу, против хреновой тучи гуёвых приложений на каждый чих

Однозадачность в стиле DOS против многозадачности. Даже сама консоль обычно из GUI работает.

необходимости запоминать набор из сотен горячих сочетаний

Горячие сочетания подписаны в самом интерфейсе.

X512 ★★★★★
()

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

InterVi ★★★★★
()

Начнем с модульности и монолитности. Суть монолитного ядра не в том, чтобы нельзя было подгружать модули. А суть в том, что сколько бы модулей мы не подгрузили, все они загрузятся в единое адресное пространство. Здесь Вы правы, ядро доверяет своему коду и если загруженный модуль что-то испортит, то он испортит все адресное пространство ядра целиком. Никакой изоляции не предусмотрено (на самом деле есть некоторые методы, они позволяют чуть-чуть снизить риск, но полностью его не устраняют).

Но… постойте, ядро винды работает точно также. В винде все драйверы тоже подгружаются в одно единое адресное пространство. И тоже ошибка в одном драйвере затронет все ядро целиком.

Поэтому да, написание драйверов или модулей ядра – это очень ответственный процесс. И именно поэтому Microsoft для винды ввела целый специальный механизм цифровых подписей. Механизм этот тоже не панацея, но, наверное, чуть-чуть от совсем уж дураков защищает.

Таненбаум прав с академической точки зрения. На современном уровне развития железа, его правоту трудно реализовать. Линус тогда очень коротко ответил, что в микро-ядре не учитывается сложность реализации механизмов связи между сервисами. Я бы еще добавил, что сложно также сделать изоляцию, но здесь вроде есть подвижки, в плане поддержки со стороны железа.

Чтобы пояснить это, нужен небольшой экскурс в устройство ядра, процессоров и железа вообще.

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

Таким нехитрым способом научились кодировать числа в двоичной системе (есть сигнал, нет сигнала) и научились делать некоторые операции над числами. Уже круто. Потом, чуть позже, пользуясь теми же электрическими цепями, научились хранить сигнал. Там как-то его зацикливать, обновлять… тут больше физики объяснят. Короче, изобрели память.

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

Отлично! Умеем сохранять числа в память по некоторым адресам и запрашивать их потом из памяти обратно. Есть только одна ма-а-аленькая проблемка… у нас теперь емкость памяти ограничена количеством проводков в шине между процессором и памятью. Потому что по количеству проводков определяется разрядность числа адресующего ячейки. И больше ячеек воткнуть не получится, процессор их не сможет адресовать.

Что же делать? Увеличивать разрядность шины? Даже если мы добавим еще один проводок в нашу шину данных, где гарантия, что больше проводков не потребуется? Таких гарантий нет. Поэтому пошли другим путем. Сделали сегментную адресацию памяти. Нет, конечно, законы физики обойти нельзя, и процессор по прежнему может адресовать ограниченный объем памяти. По сути по размеру своих регистров. Большее число просто не влезет в регистр. Но теперь разделили виртуальный адрес в памяти и реальный, физический. Благодаря этому разделению, программа, как бы, могла работать с большим объемом памяти, чем процессор мог адресовать на деле. Программа оперировала уже виртуальными адресами, сегмент + смещение, из которых процессор вычислял реальные, физические адреса памяти.

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

Чтобы исправить это, начиная с процессора i286 был введен защищенный режим. В самом 286-м защищенный режим хоть и уже появился, но был несколько кастрирован, там, вроде, еще не было страничной организации памяти, да и сам процессор был 16-ти разрядным. Полная поддержка была сделана только в i386. Поэтому, по сути, с этого процессора ведется новая веха в истории.

В защищенном режиме как раз таки и была сделана изоляция программ друг от друга. Каждая программа может работать в своем собственном контейнере. Виртуальные адреса памяти для каждой такой программы свои собственные.

Та программа, которая переводит процессор в защищенный режим работы – полностью властвует над миром. По сути, она этот мир и создает. И как она создаст, так и будет. Процессор предоставляет ей для этого все возможности.

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

Важное следствие из этого, что процесс даже если очень захочет, не сможет залезть в чужие адреса. Нужного дескриптора в таблице нет – извините, реальный адрес без него никак не вычислить.

Каким образом ядро получает управление обратно, когда запускает процесс на исполнение? Несколькими способами. Во-первых, программирует системный таймер – устройство на материнской плате. Управление к ядру вернется, когда процессор переключится на обработку прерывания от этого таймера. Про прерывания уж рассказывать не буду, и так много написал.

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

А почему процесс без ядра ничего не может? А вот как раз потому, что процессор на аппаратном уровне это регулирует. Есть так называемые круги защиты. Инструкции процессора делятся по этим кругам защиты. Какие-то инструкции можно исполнять, какие-то запрещены в том или ином круге.

Сейчас операционные системы, что винда, что линукс, что *bsd, используют только 2 круга защиты. Ядро операционной системы работает в одном круге, запускаемые процессы – в другом. Когда процессу надо выполнить какую-либо привилегированную инструкцию, он просит об этом ядро.

Ядро может делать с процессом все, что угодно. Все-равно же управление вернется к ядру. Если процесс, умышленно, или по ошибке допустил какую-то некорректную операцию, генерируется прерывание, процессор переключается на код обработчика прерывания, управление возвращается ядру. Ядро может снять процесс, выгрузить его код совершенно безболезненно для себя и для других процессов. Так работает изоляция памяти. Со своими модулями ядро так сделать не может. Поскольку в его пространстве изоляции памяти аппаратно нет.

И хотя современные процессоры поддерживают несколько кругов защиты, больше, чем 2 используемых, в них, по-сути, очень низкая надобность. Потому что защищенный режим всего 1. И другой изоляции памяти пока нет. Да, можно ограничить число дозволенных операций, поместив драйверы, например, в отдельный круг. Но смысла большого нет. Так как изоляции по памяти все-равно не будет.

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

hibou ★★★★★
()
Ответ на: комментарий от hibou

Я вот там где-то в середине текста вкратце сказал, что в современном железе есть подвижки по изоляции памяти. В современных процессорах есть режим гипервизора. Не знаю, как точно называется. Т.е. когда запускается гипервизор и уже он запускает ядро операционной системы. И вроде как тут можно несколько операционных систем запустить. Но эту часть современную я плохо знаю.

Возможно когда-нибудь это можно будет использовать для построения микроядер.

hibou ★★★★★
()
Ответ на: комментарий от hibou

Хороший текст, жаль он потеряется в этой мусорной теме.

EXL ★★★★★
()

Про то что Linux пора распиливать - согласен. В ядре оставить только основные подсистемы. Стабилизировать API/ABI. А драйвера к железу пусть живут как сейчас Out-of-tree модули. Иначе линуксу песец настанет лет через 5. Он уже сейчас огромная пингвинья скотина.

FixingGunsInAir
()
Ответ на: комментарий от EXL

Кстати, насчёт устаревшего API.

Нет простого способа атомарно отредактировать символическую ссылку.

Строго говоря, нет вообще способа отредактировать символическую ссылку; только пересоздать.

Как обычно, приходится всё делать через rename().

wandrien ★★
()
Ответ на: комментарий от damix9

Откуда - гугли, есть разные источники. 2012-13.

hakavlad ★★★
() автор топика
Ответ на: комментарий от EXL

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

И на что я его должен изменить? Что лучше ковырять бинарное дерьмицо?

crutch_master ★★★★★
()
Ответ на: комментарий от EXL

Но раз Linux «напофиг» кладёт в /sys/ и /proc/ файлики с рандомным форматированием

Давай теперь подробно без ко-ко-ко, где там какое рандомное форматирование «на пофиг»? Когда и как менялись форматы файлов в /sys/ и /proc/? Что там такое лежит, что тебе неудобно парсить.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от EXL

Подход «всё есть файл» тоже откровенно говоря хреново работает и не особо оправдал себя.

А разница в чём? У объекта есть поля и вложенные объекты, у фс - файлы/каталоги. Надо достать что-то - читаешь файл. Надо положить - пишешь в файл. Всё просто и работает из любого недоязычка, который умеет в фс. Тебе не нравится формат в sys? Ну извини, формат объекта/выхлопа жсон/хмл никому тоже не обязан будет нравиться.

Так используем их, а не ковыряемся с дерьмом из лапши регулярок и sed/awk магии для получения примитивных данных

Пишешь опять бредятину. Если тебе нальют говна в поле объекта, то ты, конечно не побежишь парсить его регулярками, а так сожрешь. Я тебе уже развёрнуто это объяснил про плохое А против хорошего Б, но ты игнорируешь всё, что тебе неудобно и включаешь тупого раз за разом.

crutch_master ★★★★★
()
Ответ на: комментарий от system-root

Очень некачественный текст. Но на лоре последнее время любой высер набирает три страницы комментов, потому, что очень скучный ресурс стал.

Да всем насрать на него у нас тут уже свой холивар.

crutch_master ★★★★★
()
Ответ на: комментарий от system-root

Я уверен, что «Подход «всё есть объект»»

Определение объекта в студию, будьте добры.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от EXL

Подход «всё есть файл» тоже откровенно говоря хреново работает и не особо оправдал себя

Чтобы он себя оправдал или не оправдал, он должен быть. А ты где его видел в линуксе? Гуй такой подход не использует. Там костыли для иксов/вяйленда и dbus. Сеть такой подход не использует. У сустемд тоже свои костыли. В старых инитах юзали эти твои регулярки с /proc, а чтобы сделать свою иерархию каталогов с демонами, чтобы echo 1 > /srv/apache/restart такого не помню, чтобы где-то было.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от EXL

так предоставьте же нормальное и удобное для этого случая API

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Давай ты определишься как оно будет выглядеть

Как в Haiku, macOS или Windows:

#include <kernel/OS.h>

uint32 count = 0;
get_cpu_topology_info(NULL, &count);
if (count != 0) {
    cpu_topology_node_info *topology = new cpu_topology_node_info[count];
    get_cpu_topology_info(topology, &count);
    for (uint32 i = 0; i < count; ++i) {
 		if(topology[i].type == B_TOPOLOGY_CORE) {
 			cpuFreq = topology[i].data.core.default_frequency;
 		}   
    }
    delete[] topology;
}

Вместо теребонькания /proc/cpuinfo и попыток каждый раз написать велосипедный кривопарсер для получения примитивной информации.

На прочий твой словесный понос отвечать лень, уж извини, занят. Если для тебя написание кривого велосипедного парсера по типу такого Serious-Engine выглядит лучше #include <kernel/OS.h>, то мне нечего тебе сказать.

EXL ★★★★★
()

Почему Линукс устарел?

Может потому, что он старый?

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

Потом качественный скачок и на новом витке все снова простое как топор.

Пока мы видим усложнение.

utanho ★★★★★
()
Последнее исправление: utanho (всего исправлений: 1)
Ответ на: комментарий от wandrien

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

Зацени кстати такую штуку в движке игрушки Serious Sam:

https://github.com/icculus/Serious-Engine/blob/29c44aed166872552c4e4c353ff6db4c3f0c08df/Sources/Engine/Base/Timer.cpp#L331-L394

Даже блин во FreeBSD добавили немного удобства:

__int64 mhz = 0;
size_t len = sizeof(mhz);

sysctlbyname("hw.clockrate", &mhz, &len, NULL, 0);
tm_llPerformanceCounterFrequency = tm_llCPUSpeedHZ = (__int64) (mhz * 1000000);

Вместо ручного парсинга /proc/cpuinfo корявым велосипедом и простынёй кода ниже. Сборка под Linux именно в эту ветку «ковыляет».

А комментарий // !!! FIXME : This is an ugly hack. как бы нам тонко намекает, что это решение станет постоянным.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от wandrien

Удачного парсинга.

Спасибо, мне и так страданий хватает.

EXL ★★★★★
()

Ядра же с современными архитектурами умеют просто выгрузить сбойный модуль и спокойно продолжить работу

Например какие?

недавнее добавление поддержки PCI-E 2.0, в 2012 году

Палишься, чувак. Паста ну очень тухлая.

no-such-file ★★★★★
()
Ответ на: комментарий от wandrien

Этот код не мой, а https://github.com/icculus | http://icculus.org/

Человека, который является активным разработчиком SDL2 на Linux и портировал сотни игр на Linux в т. ч. и по заказам различных Game Developers Studios, раз он воспользовался таким хаком, значит на то были причины, например, https://stackoverflow.com/a/63577574

EXL ★★★★★
()
Ответ на: комментарий от wandrien

Открыл исходники libcpuid, пфф:

https://github.com/anrieff/libcpuid/blob/ccd0ec842652aa094c4f95d3509a96c27fdc202f/libcpuid/rdtsc.c#L113-L149

А потом все делают глупые лица и спрашивают почему для Linux-дистрибутивов прикладные разработчики не хотят портировать софт.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Ууу. Всё понятно. Сишная дрисня, указатели и отстреленные ноги с пересборкой при переезде на новое ядро. Молодец, с задачей справился на отлично!

На прочий твой словесный понос отвечать лень

Так слейся и не отвечай. Всё с тобой понятно.

crutch_master ★★★★★
()
Ответ на: комментарий от wandrien

Ты что? Как он распарсит cpuinfo_max_freq? Там же надо паравоз из 15-и грепов.

crutch_master ★★★★★
()
Ответ на: комментарий от EXL

P.S.

EDIT2: Some processors may have /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_nominal_freq file, e.g. POWER9

Так и представил картину как какой-нибудь IBM-программист читает чей-то кривопарсер /proc/cpuinfo, крутит пальцем у виска и добавляет cpuinfo_nominal_freq хотя бы для POWER9.

EXL ★★★★★
()
Ответ на: комментарий от crutch_master

Так слейся и не отвечай. Всё с тобой понятно.

Да нет, в этом треде слился не я. Просто ты ещё этого не понял. Ничего, подрастёшь, опыта наберёшься и поймёшь.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Да да. Как кричать «фи, текст - говно», так вперёд, как предложить что-то принципиально лучше, так сишные либы и приваривание к ядру и «это вы все слились! Подрастешь - поймешь!» и т.д.
И опять же. Ты игнорируешь неудобный для себя тезис «плохое А против хорошего Б» напрочь. В твоём сишном коде через 10 лет никто не гарантирует, что ты не получишь сегфолт на ровном месте или не те данные.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от crutch_master

предложить что-то принципиально лучше

Лучше – смотреть по моим ссылкам в секциях #ifdef __APPLE__, #elif PLATFORM_FREEBSD, #elif PLATFORM_WIN32 и #elif PLATFORM_FREEBSD.

На этом заканчиваю глупый спор с тобой.

EXL ★★★★★
()
Ответ на: комментарий от crutch_master

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Аргументы и даже примеры отчётливо их демонстрирующие, а ещё причины по которым были выбраны именно такие способы – я здесь привёл

На что я тебе сказал : «плохое А против хорошего Б». Ты или забил, или ничего не понял, или решил, что априори умнее всех (или всё сразу).

crutch_master ★★★★★
()
Ответ на: комментарий от EXL

Этот код не мой

Я вижу, что не твой. Но ты же ссылаешься на него.

Человека, который является активным разработчиком SDL2 на Linux

Человека, которая является активным разработчиком SDL2 на Linux, не знает как вызывать fopen() на Linux. После этого разговор о квалификации и чем-то еще можно уже не начинать.

wandrien ★★
()

Оно монолитное, этим все сказано. Для встраиваемой техники это, безусловно, может быть полезным, но для ПК это выливается в отсутствие гибкости и стабильности. Если в монолитном ядре произойдет сбой — конец.

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

Ядра же с современными архитектурами умеют просто выгрузить сбойный модуль и спокойно продолжить работу.

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

torvn77 ★★★★★
()
Ответ на: комментарий от EXL

https://github.com/anrieff/libcpuid/blob/ccd0ec842652aa094c4f95d3509a96c27fdc202f/libcpuid/rdtsc.c#L113-L149

f = fopen("/proc/cpuinfo", "rt");
fgets
strncmp(line, "cpu MHz", 7)
sscanf

Ты рофлишь что ли??? Решил весь говнокод сюда покопипастить?

А потом все делают глупые лица и спрашивают почему для Linux-дистрибутивов прикладные разработчики не хотят портировать софт.

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

wandrien ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.