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)
Ответ на: комментарий от wandrien

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

Другого у нас в Linux и нет.

Вот потому текст вместо API в этом месте – говно, плодящее уязвимости.

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

Я это знаю. В данном случае проще написать rb.

Это были ссылки в подтверждение твоих слов, rb на открытие текстового файла зачастую можно увидеть в коде, который предназначен для Linux и UNIX. Впрочем, я бы написал точно без b, просто на всякий случай.

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

Другого у нас в Linux и нет.

Нормальных кодеров в Linux нет? Извини, но есть.

Вот потому текст вместо API в этом месте – говно, плодящее уязвимости.

Мозги просто надо иметь.

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

wandrien ★★
()
Ответ на: P.S. от EXL

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

Бред. В /proc/cpuinfo на Интеле та же самая максимальная частота с учетом турбобуста. Это не от ядра зависит, а от драйвера.

wandrien ★★
()
Ответ на: P.S. от EXL

cpuinfo_nominal_freq

Ядро в /sys не выставило значение cpuinfo_nominal_freq.

Объектный код не выставил значение в cpuinfo->nominal_freq.

Как говорится, найдите три отличия.

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

API на объектах

сишная портянка с циклом for() и чтением полей структур

Мда.

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

Никогда не поверю, что вот это вот:

https://github.com/sde-gui/waterline/blob/e0dce55a4fbc5cd4b49d45bb6fbe80a9419870af/src/plugins/cpufreq/cpufreq.c#L93-L98
https://github.com/sde-gui/waterline/blob/e0dce55a4fbc5cd4b49d45bb6fbe80a9419870af/src/plugins/cpufreq/cpufreq.c#L74-L84

Лучше sysctlbyname("hw.clockrate", &mhz, &len, NULL, 0);, GetCPUSpeedHz(); и др.

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

Бред. В /proc/cpuinfo на Интеле та же самая максимальная частота с учетом турбобуста. Это не от ядра зависит, а от драйвера.

Эм?

$ cat /proc/cpuinfo | grep 'model name' | head -1
model name	: Intel(R) Core(TM) i3 CPU       M 370  @ 2.40GHz

$ cat /proc/cpuinfo | grep MHz
cpu MHz		: 1288.594
cpu MHz		: 1449.189
cpu MHz		: 1189.446
cpu MHz		: 1053.460

$ stress --cpu 4 --timeout 10 &

$ cat /proc/cpuinfo | grep MHz
cpu MHz		: 2393.943
cpu MHz		: 2393.944
cpu MHz		: 2393.947
cpu MHz		: 2393.943
EXL ★★★★★
()
Ответ на: комментарий от wandrien

Я писал что функцию вызывать было бы проще, чем городить всё это. И гораздо безопаснее с точки зрения прикладного программиста. Особенно в C и C++.

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

Я писал что

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

функцию вызывать было бы проще, чем городить всё это. И гораздо безопаснее с точки зрения прикладного программиста. Особенно в C и C++.

Так функцию или «API на объектах».

Вот /sys — и есть самое настоящее API на объектах. Всё, как просили. Не нравится парсить на Си? Парсите питоном.

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

Может и перепишу. Там более актуальные таски есть. Или ты готов покодить на меня бесплатно?

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

А, ну или текущая. Тем более тогда непонятна предъява. Суть в том, что никакой nominal_freq там и не пахнет.

Моя предъява: прикладные программисты открывают файлы и пишут парсеры для элементарнейших вещей вместо того, чтобы вызывать GetCPUSpeedHz(), GetCPUName(), GetCPUSomeShit() и ехать дальше, решать конкретную задачу, а не думать о том, будет ли мой быстро накиданный наколенный парсер безопасным и неговнокодным?

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

Ты мне кидаешь ссылку на ВИО где что-то про параметры частоты какого-то POWER-а. Она должна что-то подтверждать. Что?

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

Расскажи сначала, зачем тебе вообще в приложении узнавать частоту процессора.

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

Так функцию или «API на объектах».

Мне, пожалуйста, что-нибудь чтобы можно было легко достать в C и C++. Объект, структура, функция, трейт, монада О_о или ещё какая дичь – не имеет значения. Текст здесь неудобен для использования. Это пример того места где концепции «текст универсальный интерфейс» и «всё есть файл» – неудобны. У ядра что нет во внутренних структурах этой информации в удобоваримом виде, чтобы отразить их в сишных хедерах?

Ведь можно было бы и по уму – отразить в API ядра и текстом, пожалуйста, для тех кому нужно. Было бы двойное удобство.

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

Если в /sys что-то переделать, у тебя часть функций в прикладной программе просто работать не будет. (Если писал по уму без разыменований нуля где ни попадя.)

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

А поскольку http://www.lorquotes.ru/view-quote.php?id=5913 , то я всё-таки предпочту первый вариант.

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

Она должна что-то подтверждать. Что?

Извини, я не расписал. Эта ссылка отвечает на вопрос почему icculus выбрал парсинг /proc/cpuinfo, вместо парсинга /sys/devices/system/cpu/cpu*/, но в обоих этих случаях – от обёрток на открытие файла, парсинга/перевода значений никуда не дется. Она только для этого вопроса.

Расскажи сначала, зачем тебе вообще в приложении узнавать частоту процессора.

Зачем либа для получения информации о процессоре libcpuid должна узнавать частоту процессора? Хороший вопрос. Ну или же тебе вот понадобилось в прикладной задаче узнавать частоту CPU? Ты её выводил на панельку скорее всего. Виджетики там, коньки. А в движке игры там видимо как-то таймеры анимаций на частоту завязаны, ибо она довольно старая.

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

Эта ссылка отвечает на вопрос почему icculus выбрал парсинг /proc/cpuinfo, вместо парсинга /sys/devices/system/cpu/cpu*/

Как она отвечает?

Зачем либа для получения информации о процессоре libcpuid

Ну вот видишь, либа уже есть для этого. Значит проблема высосана из пальца.

Ты её выводил на панельку скорее всего.

Это маргинальные случаи, для которых нет нужды тащить отдельное API.

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

Ну короче говнокод.

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

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

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

Ты бы потратил гораздо меньше времени, подрубив какой-нибудь "#include <cpuinfo.h>` и вызвав пару функций, вместо этих жонглирований файлами, буферами и парсингом.

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

А не нужно ничего переделывать в /sys/

Это не вопрос нужно или ненужно, а вопрос, через сколько лет твой прикладной код отвалится. Ничего вечного нет.

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

Когда и как менялись форматы файлов в /sys/ и /proc/?

В 5.8 или 5.9 изменился формат /proc/swaps (добавлены лишние \t - это улучшило визуальное восприятие файла, но сломало скрипты), из-за этого у меня пара скриптов сломались.

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

Ну вот видишь, либа уже есть для этого. Значит проблема высосана из пальца.

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

Как она отвечает?

There is not a single universal way how to read the nominal frequency. You can read the nominal frequency of Intel processor from /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq (nominal + 1 MHz) when using acpi-cpufreq scaling driver, however intel_pstate sets content of this file to maximum turbo frequency. Nevertheless there are alternative solutions. Intel CPUs have the nominal frequency written as a part of the CPU model name (readable using CPUID instruction when input EAX = 0x01 or from /proc/cpuinfo) or you may read the MSR_PLATFORM_INFO (0xCE) register.

Другими словами, /proc/cpuinfo – будет наиболее переносимым.

И кстати, почему вот так сделано? Лично я теряюсь в догадках.

$ cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied
cat: /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq: Permission denied
cat: /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_cur_freq: Permission denied
cat: /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq: Permission denied

Это в Fedora 33, дефолтной Если я соберу твою панельку waterline – получится ведь тыква?

Ну короче говнокод.

Да, как в любых проектах. Никто не будет сильно переписывать изначальный говнокод для того чтобы портировать проект на Linux.

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

Паста ну очень тухлая

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

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

Нет, ну если сделать лозунгом «stable api nonsense», то конечно. Вот только в приведённых мной примерах API у BSD/Haiku/Windows/macOS что-то нихрена не отваливается.

Я поставлю, что скорее всего отвалятся кривые парсеры с очередным улучшением вёрстки /sys/-файлов которыми кишит прикладной Linux-код, чем подобные API.

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

изменился формат /proc/swaps (добавлены лишние \t - это улучшило визуальное восприятие файла, но сломало скрипты), из-за этого у меня пара скриптов сломались.

А я заметил изменение вёрстки /proc/meminfo, правда х.з. в каких версиях. Там в том коммите нет ничего про него? Некоторая дрисня из sed/awk/grep тоже отлетела, правда не моя.

В /proc/cpuinfo пока только припоминаю внесение секций по типу bugs:

$ cat /proc/cpuinfo | grep bugs | head -1
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от EXL

Не припоминаю крупных изменений в меминфо в последнее время. Разве что новые пункты постоянно добавляются.

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

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

Парсер написать прикладник не смог, а виновато ядро. Логика…

There is not a single universal way how to read the nominal frequency.

Это nominal. Мы уже выяснили, что в /proc/cpuinfo нет номинальной частоты вообще, только текущая.

Другими словами, /proc/cpuinfo – будет наиболее переносимым.

Он вообще не будет переносим. Там нет этой информации.

Да, как в любых проектах. Никто не будет сильно переписывать изначальный говнокод для того чтобы портировать проект на Linux.

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

Это в Fedora 33, дефолтной Если я соберу твою панельку waterline – получится ведь тыква?

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

У меня вообще:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Нет такого файла или каталога

А частоту он отображает в подсказке, проверил. Значит частота берется из scaling_cur_freq.

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

Вот только в приведённых мной примерах API у BSD/Haiku/Windows/macOS что-то нихрена не отваливается.

/me пристально смотрит на доменно имя сайта.

Я поставлю, что скорее всего отвалятся кривые парсеры с очередным улучшением вёрстки /sys/-файлов которыми кишит прикладной Linux-код, чем подобные API.

Лицоладонь. Там нет никакой верстки, там сырые значения.

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

Ничто не мешает ядру изменить формат структур в #include <kernel/OS.h>. И?

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

Парсер написать прикладник не смог, а виновато ядро. Логика…

Ты так мне и не объяснил, нахрена программисту писать какой-то кривой (или некривой) парсер вместо быстрого решения элементарной задачи. Чтобы потренироваться в написании парсеров?

Что мешало отразить эти данные в хедере, в структуре? Что мешало сделать как во FreeBSD?

/me пристально смотрит на доменно имя сайта.

Ну мы же не будем ударяться в фанатизм и будем рассматривать решения в зависимости от удобства их применения и той же безопасности.

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

Лицоладонь. Там нет никакой верстки, там сырые значения.

В /proc/cpuinfo – вёрстка.

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

Ну мы же не будем ударяться в фанатизм и будет рассматривать решения в зависимости от удобства их применения и той же безопасности.

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

Что мешало отразить эти данные в хедере, в структуре? Что мешало сделать как во FreeBSD?

На каждый чих делать API? Ну вот и будет Линукс в таком же примерно состоянии разработки, как и в FreeBSD.

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

Ядро предоставило «универсальный объектный подход», всё как просили. То, что прикладники не смогли завернуть этот подход в абстрации своего ЯП — не проблемы ядра.

Ты так мне и не объяснил, нахрена программисту писать какой-то кривой (или некривой) парсер вместо быстрого решения элементарной задачи. Чтобы потренироваться в написании парсеров?

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

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

Актуальность

Где? То что ты колупаешься в тухлятине не делает её актуальной. Актуальна она лишь в том, что примеров «Ядер с современными архитектурами» которые можно пощупать не в пробирке не было тогда, нет и сейчас. Поэтому ты так актуально заткнулся и засунув язык в жопу проигнорировал неудобный вопрос, который я тебе задал. Такие дела.

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

На каждый чих делать API?

То есть ты считаешь, что на каждый чих писать парсер – более здравый подход?

Ну вот и будет Линукс в таком же примерно состоянии разработки, как и в FreeBSD.

Кроме Linux’а API пишется в других OS, у которых состояние разработки отличное от FreeBSD.

Почему вопросы качества кода этой библиотеки должны быть областью ответственности ядра? А что еще ядро должно, DE предоставить?

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

Так и живём.

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

У той же фряхи, насколько я понимаю, тупо есть функция, которая принимает имя параметра и возвращает значение. В чем проблема раз и на всегда написать такую под линуксом в юзерспейсе? При чем тут ядро? Ядро предоставило все необходимое.

Ладно в отличие от /sys с файлами в /proc старый факап. Но к ним тоже можно раз и навсегда парсер написать. Качественный парсер к cpuinfo пишется за час. Без sscanf и темной магии с захадкоженными длинами строковых констант.

Извини, но если для линукса парсер примитивного и простого как полено формата написать некому, то вопрос надо ставить не так что почему API плохое, как эта ОС вообще еще не развалилась.

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

В чем проблема раз и на всегда написать такую под линуксом в юзерспейсе?

Это спрашивать нужно, например, программистов GNU, почему они не предоставляют какую-нибудь libhardware с проверенными функциями, парсерами, структурами и т. д.

При чем тут ядро? Ядро предоставило все необходимое.

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

но если для линукса парсер примитивного и простого как полено формата написать некому

Да, все пишут на свой лад, каждый раз по новой, потому что «libcpuid» какая-то мутная, а не системная либа идущая в дистрибутиве и предоставляющая проверенное и рабочее решение.

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

Как говорится, найдите три отличия.

Он не способен воспринимать этот аргумент. Ведь это значит, что в плане адекватности исходных данных нет никакой разницы где они лежат, а значит всё, на чем он строит свою аргументацию идёт лесом и всё, что остаётся - это «мне так удобно доставать это из крестов/сишечки». То, что его софт будет работать только с конкретным ядром ему тоже похер. Да, на другом ядре какие-то скрипты с седами отвалятся (а какие-то будут работать как работали и никто ничего не заметит), но его софтина сегфолтнится из-за изменения структур и работать не будет точно (ну и что, что надо всё перекомпилять, зато парсер переписывать не надо!).

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

Он не способен воспринимать этот аргумент.

Это ты не способен воспринимать аргументы в силу определённых умственных причин.

То, что его софт будет работать только с конкретным ядром ему тоже похер.

Ну давай, расскажи мне, теоретик, как софт использующий функции вида: sysctlbyname() (FreeBSD), GetCPUSpeedHz() (Windows), GetCPUSpeed() (macOS) работает только с конкретным ядром и сегфолтится на других.

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

Первая версия https://github.com/hakavlad/nohang-extra/blob/05d3ea498a318e79716d7cc8a3541f136bfa1c4f/zram-info

Исправленная https://github.com/hakavlad/nohang-extra/blob/master/zram-info

/proc/swaps Сейчас:

Filename\t\t\t\tType\t\tSize\t\tUsed\t\tPriority\n/dev/zram0                              partition\t40073036\t0\t\t100\n

Раньше:

Filename\t\t\t\tType\t\tSize\t\tUsed\t\tPriority\n/dev/zram0                              partition\t40073036\t0\t100\n
hakavlad ★★★
() автор топика
Последнее исправление: hakavlad (всего исправлений: 3)
Ответ на: комментарий от hakavlad

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

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