GNU/Linux

там из GNU уже glibc только. по историческим причинам GNU. и то поттер порывается ее переписать. systemd/Linux будет вернее.

В C++ можно сразу посылать за использование голых массивов.

Что такое голый массив?

Если есть голый, то должен быть одетый массив)))

несколько несомненно важных GNU-утилит

Несколько десятков (а то и сотен) — если быть более точным. Но основных крупных системных программ в юзерспейсе действительно всего несколько: загрузчик (GNU GRUB), базовые системные утилиты (GNU Core Utils), shell (GNU Bash), компилятор (GCC — GNU CC), библиотека системных вызовов (Glibc — GNU C Library) и ПО для обращения с объектным кодом в объектных файлах (GNU Binutils).

Также следует обратиться к истории. Исторический контекст ведь очень важен. Необходимо знать причину, условия и факторы, при которых образовалась ОС GNU. А это — необходимость в свободной замене Unix.

Факт в том, что сначала была начата разработка операционной системы GNU (т. е. полноценной и самостоятельной ОС), затем стадия разработки дошла до того, что сама свободной системы для замены Unix уже была готова, но возникли сложности с ядром GNU Hurd (из-за его микроядерной архитектуры, которая требует больше аремени и усилий, несмотря на очевидные преимущества). К этому моменту финский студент Линус Торвальдс написал just for fun ядро (как он сам заявлял: «я написал ядро Linux, но это не такой серьезный и крупный проект, как ОС GNU»), а его знакомый опубликовал его на FTP-сервере (с лицензированием под GNU GPL в последствии).

Это стало причиной появления различных дистрибутивов (как Linux и GNU по отдельности, так и систем-франкенштейнов — GNU с ядром Linux).

не меняют название семейства OS

Да, если речь о семействе ОС Linux (Alpine Linux, OpenWrt, Android, — это все в первую очередь; сюда же относятся системы семейства ОС GNU, если они имеют ядро Linux: Debian GNU/Linux, PureOS и т. д.). Таким образом, если у системы ядро Linux, то такую систему называть Linux'ом можно и нужно (точно не будет ошибкой). В этом случае речь будет идти о системе, как принадлежащей семейству Linux. В случае, если система имеет юзерспейс GNU, то ее можно и нужно называть ОС GNU (речь будет идти о семейства GNU). Среди семейства ОС GNU есть системы без ядра Linux (с ядром от GNU — GNU Hurd). Так, например, GuixSD — дистрибутив не только GNU/Linux-системы, но и ОС GNU, т. к. из него на выбор можно развернуть как систему семейств GNU/Linux и Linux, так и ОС GNU. Во втором случае можно уточнить в названии: ОС GNU + GNU Hurd или GNU (Hurd). К системам семейства GNU относятся как чисто GNU-системы (GuixSD, Debian GNU/Hurd, Arch Hurd и т. д.), так и GNU с ядром Linux или kFreeBSD (Ubuntu, Fedora и т. д.).

Таким образом, одна операционная система может относиться сразу к двум семействам (или подсемействам — в зависимости от классификации). Здесь имеем дело с ложной дихотомией.

Тогда уж Modula-2

https://wandbox.org/permlink/dJfjJPm8HFgGviNI

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

Эти ваши сусмудэ и пышьаудио мне столько кровки попили, что ололо. Почему у меня наушники не работают в дискорде?! Дизлайк и отписка. Красная шляпа - корпорация зла.

Не напоминай. Я из-за пшпшаудио в 2009 чуть назад на венду не вернулся. Эту хрень пропихнули насильно во всякие убунты тогда. У тебя в дискорде наушники не работают, а у меня тогда в фильмах и музыке звук прерывался постоянно на несколько секунд, но зато на каждом форуме фанатики кричали «вы ничо ни панимаити, так и должно быть!». Хорошо, я, тогда еще неопытный, догадался все ж отключить эту гадость и использовать чистую альсу. Тогда я удивился, насколько чистым и хорошим может быть звук в линуксе. С тех пор никаких пшпшаудио. Хотя ее, говорят, закопали уже

Понимаешь в чём дело. PulseAudio внедрили, включив его в дистрибутивы по умолчанию, и не предоставив настолько же простого способа выключить, какой был у ESD и aRts (в KDE Control Center заходишь в Sound и просто убираешь галочку «Use sound server»). Фактически это был подход советской обязаловки, когда всем сказали сдавать говно, и все пошли сдавать. При этом ты имеешь право отказаться сдавать говно, но тогда тебе скажут «чел, нам и самим это не нравится, только это уже стало нормой, и все это делают. А если ты не хочешь, значит ты против общества, значит ты против нас».

Точно так же, когда все перешли на новые Ubuntu, где «пульса» была уже по умолчанию и не выключалась, на тех, кому пульса не нравилась, стали косо смотреть и делать изгоями, выставлять маргиналами.

coreutils, GCC, binutils, util-linux?

Каких?

Скорее наверное без ручного управления памятью.

В С все аллоцируется на стеке потому что это единственный Raii, который там есть. Стек очистится сам.

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

А если динамической памяти нет, или нужна производительность - есть арены и polymorphic memory resource, что опять сильно упрощает работу с памятью позволяя сосредоточиться на реальных проблемах.

В-третьих, есть хорошо отлаженные стандартные алгоритмы. Используя их уже на 99,99% снижается вероятность улететь за пределы контейнера. Опять же можно сфокусироваться на решаемой проблеме, а не на условии выхода из цикла.

вторая уязвимость в systemd.

Пора уже переименовывать в linuxd, всё равно эта вундервафля только на линуксе работает.

std::byte buffer[512];

А 512 точно хватит?

systemd/Linux будет вернее.

Да надо уже ядро в kerneld переименовать и признать, что линукс потрачен.

Для переполнения стека — нет.

Теоретик?

Нужно увеличить до 256К!

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

Да никак. Не спорь с ними :-Д Мамкиных экспертов не переубедить.

Если на стеке не хватает, надо, очевидно, выделять в хипе.

Ну т.е. на стеке довыделить нельзя. Ч.т.д.

да-да, но без всего этого можно обойтись.

Серьёзная победа си над C++ — в C++ невозможно воспроизвести сишные баги.

признать, что линукс потрачен.

что у вас за новый мем с этим «потрачено» появился?

Да надо уже ядро в kerneld переименовать

не, это никак не выйдет. надо с юзерспейса начинать. поглотить сначала главную библиотеку. потом добавить реализацию core-utils на расте. причем модулем к какому-нибудь другому большому проекту.

Серьёзная победа си над C++ — в C++ невозможно воспроизвести сишные баги.

Ну вообще-то твой std::byte buffer[512]; вполне себе может переполнить стек, например в ситуации, когда у тебя этот самый стек заканчивается, и выделение 512 байт его как раз переполнит.

что у вас за новый мем с этим «потрачено» появился?

Это из кривого пиратского перевода GTA San Andreas

что у вас за новый мем с этим «потрачено» появился?

Да это старый мем, вообще-то. Из GTA San Andreas с кривой русификацией промтом. Там, когда тебя убивают, появляется надпись «Wasted», которую перевели как «Потрачено». «Охладите трахание» и «Она со мной, углепластик» оттуда же.

Зачем напрямую искажать информацию?

Я все правильно написала.

«We successfully exploited this uncontrolled out-of-bounds write, and obtained full root privileges on default installations of Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11, and Fedora 34.»

https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt

подвержены только некоторые версии

Debian 11, Fedora 34, Red Hat Enterprise Linux (RHEL) 6, 7 и 8. а также в Ubuntu версий 20.04, 20.10 и 21.04.

Это ты называешь «некоторые версии»?

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

Любая операция деления, любая операция получения памяти, …

Я первый про stack overflow написал :P

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

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

The issue results from not validating the size_t-to-int conversion prior to performing operations

Хаха. Спасибо кулхакерам из Bell, которые думали что слабая типизация - это хорошо для системного языка. Таких мин в сишном/плюсовом софте 100500, только копни.

Полная чушь.

: в сях все буфера на стеке делаются,

4.2

первых, из-за того, буферы там не надо аллоцировать, это просто делать на куче.

Так не надо аллоцировать, или просто делать на куче? Кто помешал делать malloc в С – непонятно.

Не надо сразу все переменные в начале функции объявлять

Компилятору глубоко наплевать, в начале ты их объявил, или непосредственно перед использованием. Самого требования объявлять переменные в начале нет уже почти 25 лет.

Более того, у С и С++ один компилятор. Различаются у них только фронтенды.

на специализированном ресурсе, полном технических специалистов

Имеет ли право токарь или слесарь использовать доску, если электрик забыл перчатки? Большинству «технических специалистов» ваша «писанина» не впёрлась никуда, потому что они используют гораздо более удобное. Извенити )

Так не надо аллоцировать, или просто делать на куче?

Ключевое слово «там» == «на стеке». Потому что это легко сделать на куче. Отсюда ответ на твой следующий вопрос:

Кто помешал делать malloc в С – непонятно.

Сложность всей этой процедуры. Надо следить за аллокацией, надо следить за деаллокацией. Особенно тяжело следить за деаллокацией при обработке ошибок чтобы не обоссаться (протечь). Это намного более кропотливая работа, чем повсюду пихать char buf[MAX_SIZE]. Которую на себя берет компилятор.

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

Компилятору глубоко наплевать, в начале ты их объявил, или непосредственно перед использованием.

Какой феерический бред. Иди учи матчасть.

Более того, у С и С++ один компилятор. Различаются у них только фронтенды.

Иди учи матчасть дальше. Вообще не понимаешь, о чем пишешь. Frontend - это как раз то, что отличает один яп от другого.

да то как же

CVE-2021-33909 The issue results from not validating the size_t-to-int conversion prior to performing operations.

«С» не виноват, виноваты линугсойды г0вн0к0деры. Кресты от них не спасут. Каждый раз смотрю на эти линуксойдные макароны с говнокодом и плююсь. Печально, что все российские ОС из этого сделаны.

Так и без linux можно обойтись. Debian GNU/Hurd не даст соврать.

нет-нет, меня волнует именно линукс.

У пользователя есть возможность выполнить код с root-правами.

У какого-то пользователя есть возможность выполнить какой-то код от имени рута. Даже не сказано, что произвольный. Разве это не так?)

А вообще, язабан, конечно.

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

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

Я-то на С пишу, а вот на твой счет не уверен. Если выделение памяти на буфер вызывает такие сложности, страшно представить, что случается при работе в предметной области.

Frontend - это как раз то, что отличает один яп от другого.

Как это опровергает мои слова? Или ты мне сейчас будешь рассказывать про то, что слотовые оптимизации на фронтенде происходят?

«чаще всего». Ты написал исключения из правил. А что ты предлагаешь? Каждую операцию деления и получения элемента массива возвращать в виде Optional? Это просто неразумно.

Нет никакого «как», паника это и есть исключения, названные иначе.

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

Исключения были одной из причин, по которым С++ не прошел в ядро.

Единственная причина, по которой С++ не прошёл в ядро, это предпочтения Линуса. В другие ядра С++ прекрасно прошёл и никаких проблем это не вызвало. В gcc (и во всех других известных мне компиляторах C++) исключения отключаются одним флагом.

Очень интересное ядро получается.

Да ровно такое же, как сейчас. FAQ/BUG почитай. Ну ладно, не как сейчас, чуток надёжней, конечно, как ни крути.

А в Java нет никакого std::terminate, там всегда раскручивается до конца. Если завершился главный поток, то распечатывается stacktrace. Если не главный, то ничего не распечатывается ЪУЪ

Что за хайп вокруг rust?

Да ровно такое же, как сейчас

…не считая того, что panic! вызывается на всякую чушь.

Единственная причина, по которой С++ не прошёл в ядро, это предпочтения Линуса

Ну раз так, то, наверное, и драйвер в ядро приняли с паникой, и не пришлось std переписывать?

Паника похожа на исключения, но имеется ряд отличий.

Никаких отличий не существует, кроме как с пользовательской точки зрения.

Каждую операцию деления и получения элемента массива возвращать в виде Optional? Это просто неразумно.

Внезапное падение программы разумней? Вспоминается perl с его save() || die "Cannot save your data";

Я-то на С пишу, а вот на твой счет не уверен.

Конечно же нет. Я не настолько упорот. Было бы интересно посмотреть, что там такого крутого написал.

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

Именно. в C только и занимаешься тем, что следишь за выделением памяти. Никакой предметной области.

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

И то, где этот косяк вылез - вообще смешно. В плюсах сто лет есть boost.filesystem, а теперь и стандартная.

И вот даже посмотреть, как «исправили» (код с гитхаба) -

       p = strdup(f);
        if (!p)
                return -ENOMEM;

        path_simplify(p);

        if (empty_or_root(p))
                s = strdup("-");
        else {
                if (!path_is_normalized(p))
                        return -EINVAL;

все - обоссались, если путь не нормализован. Кто p = strdup деаллоцирует? Раньше это dupa и делал.

И вот куда не плюнь - такая хрень вылезает. Еще иксперты такие, «сложности вызывает»…

В данном конкретном случае обоссались таки вы. Ибо выше:

        _cleanup_free_ char *p = NULL;

_cleanup_free_ — это макрос, раскрывающийся в __attribute__((cleanup(…))).

«I never leak» (c).

Действительно. Там даже в конце TAKE_PTR. Круто!

Говорю, я ж на С не пишу и уж тем более не в курсе всех расширений. Вон, в соседнем топике обсуждали лямбды в С (-fblocks).

Но я всё равно придерживаюсь своего мнения: зачем переизобретать C++, если уже есть готовое и стандартное?