- Линус Торвальдс не исключил возможность интеграции поддержки..., Fracta1L, 09:28 , 22-Июн-22 (1) +9 [^]
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноне, 09:37 , 22-Июн-22 (3) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:54 , 22-Июн-22 (19) +4
- Линус Торвальдс не исключил возможность интеграции поддержки..., microsoft, 10:59 , 22-Июн-22 (32) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., torvn77, 12:51 , 22-Июн-22 (92)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:55 , 22-Июн-22 (96) –1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:37 , 22-Июн-22 (2) +15 [^]
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:38 , 22-Июн-22 (4) +4
- Линус Торвальдс не исключил возможность интеграции поддержки..., Юрий, 09:42 , 22-Июн-22 (7) +9 [^]
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:47 , 22-Июн-22 (15) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., freehck, 09:54 , 22-Июн-22 (20) +5
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:14 , 22-Июн-22 (60) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:17 , 22-Июн-22 (67)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 12:35 , 22-Июн-22 (81)
>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++? > Потому что Линус в гробу видал C++.Линус тогда сказал именно то, что от него хотели услышать люди, писавшие ядро на Си. Действовал в интересах сообщества. > Его потом дебажить замучаешься. И > сломается в самый неподходящий момент. А это ядро. Это предрассудки. Но если люди привыкли писать на Си - вот тогда им будет сложно. Поэтому Линус не захотел ломать традицию.
- Линус Торвальдс не исключил возможность интеграции поддержки..., freehck, 20:15 , 22-Июн-22 (197)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 10:16 , 23-Июн-22 (250)
>>>> Непонятно только, если можно писать драйверы на Rust, то почему нельзя на C++? >>> Потому что Линус в гробу видал C++. >> Линус тогда сказал именно то, что от него хотели услышать люди, писавшие >> ядро на Си. Действовал в интересах сообщества. > Ты сейчас не Линуса описываешь. Линус тебе покажет средний палец и объяснит, > что у тебя в голове дepьмо. Последнее, чем он будет заниматься, > это писать то, что ты от него хочешь услышать. =) Это ты сейчас отвечаешь не на мой комментарий, а на какой-то выдуманный. Я не пишу ядро Lunux, потому не вхожу в множество людей, чьи интересы Линус учитывает. Что касается пальцев - Микрософт показывал мне однажды, официально заявляя, что Си++ невозможно у них в ядре. Но оказалось возможно. Так что и палец Линуса не оказал бы воздействия. Другое дело, что Си++ _не_нужно_ в дереве исходников ядра Linux.
- YOU are full of Bullshit!, freehck, 10:34 , 23-Июн-22 (253) –1
- YOU are full of Bullshit!, n00by, 10:42 , 23-Июн-22 (255)
Я _сделал_ когда-то то, чем ныне заняты растоманы. А вот если ты не смог мне что-то объяснить - это да, потому что я туповат. ;)
- YOU are full of Bullshit!, Аноним, 12:29 , 26-Июн-22 (429)
- YOU are full of Bullshit!, n00by, 12:58 , 26-Июн-22 (443)
>> Я _сделал_ когда-то то, чем ныне заняты растоманы. > Это, например, что? Прислал патчи с поддержкой другого яп в майнлайн? Да > ну?! :) Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы, что бы писать драйвера на Rust. Когда мне понадобился Си++ в ядре Виндовс, я не слал в Микрософт письма с вопросами по компилятору, а просто сел и начал писать, дальше люди помогли. При этом "сишники" никак не мешали, поскольку не было походов со своим уставом в чужой монастырь. В итоге оно заработало (при этом драйвер работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна не очень, но помогала не писать тесты, а брать готовые). У растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения?
- YOU are full of Bullshit!, Аноним, 15:40 , 26-Июн-22 (463) +1
- YOU are full of Bullshit!, n00by, 16:19 , 26-Июн-22 (465)
>> Вот в этом-то вся и соль. Зачем они хотят в майнлайн? Якобы, >> что бы писать драйвера на Rust. > Ну да. А что в этом пожелании такого плохого?В желании писать - ничего плохого не вижу. > В лине как-то > принято с апстримом кооперироваться чтобы не усложнять себе и им жизнь > лишний раз. Совместная работа над проблемой с двух сторон при наличии > понимания и более-менее консенсуса с обоих сторон - эффективнее. А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную возможность? >[оверквотинг удален] > совсем другие экосистемы и подходы и с точки зрения R&D это > вообще-то их баг а не фича. > В лучшем случае за майками можно выгрести их фекальи. В хучшем вы > там %$^тесь как хотите и всем похрен. И на разработку кернела > - так же. На его перфонмас. Фичи. И их отсутствие. Косяки. > И даже откровенные баги. Гнилая экосистема и уж не ее адептам > линуксоидов учить как надо. Просто сравнивая какие вещи напрягавшие меня и > где удалось загасить и сколько усилий это от меня потребовало так > и сяк. А майкрософт был отклассифицирован как "враждебный апстрим". И теперь > "хорошо что это не у меня". Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП. > Торвальдс предпочитает быть более конструктивным > апстримом. И кроме всего прочего не собирается счастье к глотку саплгами > заталкивать, кроме некоторых сильно принципиальных моментов, что выгодно отличает его > от майкрософта, чей маркетинг практикует это с завидным постоянством. И это не понял. >> При этом "сишники" никак не мешали, поскольку не было походов со своим >> уставом в чужой монастырь. В итоге оно заработало (при этом драйвер >> работал гораздо раньше, чем появилась поддержка исключений, которая в ядре нужна >> не очень, но помогала не писать тесты, а брать готовые). У >> растоманов уже есть какой-то драйвер, или только вот этот процесс внедрения? > Ну так хрустикам придется интерфейситься к овердофига сишной начинки, нравится им это > или нет. Это само собой разумеется. ZFS on Linux приходится, и Reiser 4 приходится. > Никто не будет ради них все ядро переписывать да > и не смогли бы в следующие цать лет. Они это или > осилят или пойдут в пень, какие еще варианты есть? Если осилят, > малацца, значит на хрусте можно и правда косиить под типа этакий > си до кучи :) На самом деле сишникам придётся качать сорцы на Rust, нравится им это или нет. Судя по комментариям, не всем нравится. И потом придётся смотреть патчи на Rust. И ревьювить... ну или так принимать. ;) > Что до виндовых дров - я не очень в курсе что там > у них, их DDK и подходы меня всегда вымораживали оверинженерностью и > сложностью, и тем что без огромной и нахреннужной мне студии шагу > ступить невозможно. В паре с общей враждебностью майков к ядерным девам > пусть им там кто другой дрова пишет, имхо. В _моей_ системе > (где я могу _моим_ ключем влепить подпись на модуль себе) такие > развлечения как-то сильно проще той порнографии которую по этому поводу предлагали > майки. Ну это сейчас так всё плохо, раньше было получше, в том числе и потому что Студия не умела собирать дрова.)
- YOU are full of Bullshit!, Аноним, 17:44 , 26-Июн-22 (471)
- YOU are full of Bullshit!, n00by, 09:48 , 27-Июн-22 (482)
>> В желании писать - ничего плохого не вижу. > Ну дык. И в совместной работе над проблемой по-моему тоже одни плюсы. Где она, эта совместная работа? Где для неё обоснованные предпосылки? Грег Кроа-Хартман собирает статистику по коммитерам. Есть данные, сколько знают Rust? Сколько готовы писать на Rust? >> А вот здесь вижу смешение понятий. Если драйвера нет, что кооперировать? Потенциальную >> возможность? > Да, а чего? Если всерьез кодить с прицелом на надежность и безопасность, > можно заметить что сишка белый, пушистый, но некоторые принципиальные тупняки в > его дизайне - есть. При том настолько фундаментальные что полностью их > заделать не могут даже мощные статические анализаторы. Правда насколько оно там > у хрустиков лучше окажется вопрос открытый и не получится ли так > что заткнув 10 проблем они поимеют 100 новых - кто ж > его знает. Ну вот, никто не знает, никто не попробовал. Готовятся к экспериментам на живом теле. В моём понимании, это стоило развить отдельно, создать что-то уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить Rust или идти подстригать газон. > А убогий отлов integer overflow как у них я > даже на совсем обкоцаном микроконтроллере могу с урезаным ubsan на сях. > Так что у меня возникло ощущение что в пиаре эти господа > лучше чем в реальной системщине. А лучше бы наоборот. Вот к этому я и клоню. Им важен не результат, а сам процесс внедрения, шум вокруг него. Зачем Гуглю этот процесс? У них есть своё новое перспективное ядро - Фуксия. Зачем им тогда Линукс? >> Я не понял, к чему это. Они контролируют ОС, но не могут запретить использовать ЯП. > Ну да. И наверное если очень захотеть, можно и для линукса так > изгальнуться. Просто это будет именно "изгальнуться". С прошибанием всех стенок своим > лбом. А оно такое надо? В Линукс это не надо, поскольку много человек долгие годы пишут ядро на Си. В Виндосе нет такого решающего фактора, как традиция и мнение сообщества, каждый сам себе паровоз. Были Керниган и Риччи, придумали Си, создали Юникс. Был Чарльз Симони, придумал венгерскую нотацию, получился в итоге Виндос. > Если цель доказать из принципа что > автомобилем можно при сильном желании сбить вертолет, ну, да, в каких-то > отдельных допущениях может прокатить. А если цель без напрягов накодить драйвер, > занимаясь написанием (логики) драйвера а не деланием мозга не очень связанными > сложностями - ну, блин. Вот мне и требовалось решать задачу, где слишком много логики, что для ядра в принципе не свойственно. В Виндовсе много технологических отверстий, потому антивирус из пространства пользователя мало что насканирует, надо быть в ядре. Пока я не вижу драйвера на Rust, где бы была такая логика, мне ситуация не очень понятна. > К тому же ABI там все же > наверное сишное, и для его соблюдения придется осетра местами урезать. Как > и исползование фич плюсов. И получатся типа плюсы, которые как бы > плюсы, но как бы не совсем плюсы. Хрустикам это тоже в > принципе все светит, но там их вроде отдрессировали сделать натяг совы > на глобус несколько элегантнее, хотя тоже костылями выглядит вообще-то :) >> И это не понял. > Я имел в виду что если вон та толпа народа хочет дрова > на хрусте кодить, а зачем им собственно лом в вентилятор ставить? А они уже кодили дрова? В Виндосе самый первый драйвер, который пишут, как правило специально генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть. > Таки да, это вызывает и у меня некоторые вопросы. Но если Торвальдс > считает что может get it right - а пусть покажет, интересно > посмотреть на это все. Торвальдс перед всей этой историй уходил в странный отпуск, что бы подумать. >> Ну это сейчас так всё плохо, раньше было получше, в том числе >> и потому что Студия не умела собирать дрова.) > Ух, я даже не знаю когда она их не умела собирать. DDK > у майков сколько я себя помню был чем-то типа нашлепки над > студией чтоли. Вот во времена DDK и не умела, в DDK шел свой транслятор в комплекте, сопровождалось это религиозным убеждением, что с другой версией обязательно случится BSOD. Потом DDK стал называться WDK. Наверное, 2008я Студия научилась собирать, зачем-то же я её устанавливал посмотреть. > А с альтернативными тулчейнами было как-то не особо. Да > еще качать DDK так просто довольно долго не давали, душась жабой. IFS Kit не давали. Прикол был в том, что вход в файловые системы только через курсы на OSR. И дело там не в жабе - они так искали специалистов.
- YOU are full of Bullshit!, Аноним, 16:20 , 27-Июн-22 (486)
- YOU are full of Bullshit!, n00by, 10:26 , 28-Июн-22 (503)
>> В моём понимании, это стоило развить отдельно, создать что-то >> уровня Reiser4 - тогда никто не сможет возразить. Придётся моча учить >> Rust или идти подстригать газон. > В смысле? Я не думаю что ядерщики перестанут принимать сишный код в > обозримом будущем. А загадывать на 50 лет вперед в таких вещах > дело неблагодарное.В смысле, что Окно Овертона открывается постепенно. Безопасность же. За безопасность так или иначе приходится платить. Обяжут. >> В Виндосе нет такого решающего фактора, как традиция и мнение сообщества, >> каждый сам себе паровоз. > И в конечном итоге желающих кодить дрова для виндов почти и не > осталось. Сейчас ломается традиция писать Linux на Си. >> Пока я не вижу драйвера на Rust, где бы была такая >> логика, мне ситуация не очень понятна. > Могу даже немного натянуть сову на глобус. Вот смотри, билдсистема кернела пиндит > если stack frame превышает 1024 байта. Большие стэкфреймы в именно ядре > с кучей всего - ведут к дурным проблемам. К сожалению это > означает что дровописаки начинают любить динамическое выделение памяти. А вот с > этим не поздравляют, ибо все-таки известный источник проблем. Именно это много лет как решает Си++ с std::unique_ptr. И я видел proposal в ISO/IEC 9899 на тему автоматического вызова функции очистки при выходе из scope. Другое дело, что мешать RAII и goto cleanup в одном проекте - не обязательно хорошая идея. >> В Виндосе самый первый драйвер, который пишут, как правило специально >> генерит BSOD разыменовыванием NULL. ИМХО что-то в этом есть. > Мне это честно говоря не очень понятно. Я даже когда фирмвари писать > учился первое что было все же помигать светодиодиком, потом сказать hello > world в уарт например. А вот NULL отдереференсить и поймать свой > HardFault - продвинутости, точно не первая штука. Я все же пишу > код не для того чтобы он валился. Фирмварь работает где-то далеко и там ошибка страницы не так наглядна, как на живой системе. Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост, ставили инженеров под него и сверху пускали паровоз.
- YOU are full of Bullshit!, Аноним, 21:56 , 29-Июн-22 (514)
- YOU are full of Bullshit!, n00by, 09:45 , 30-Июн-22 (515)
>> Сейчас ломается традиция писать Linux на Си. > Си хорошая штука но тоже со своими приколами. А навсегда утыкаться в > state of art 70х без учета новых данных и идей тоже > как-то так себе. Поэтому логично иногда опробовать иные опции. > Плюсеров понесло куда-то не туда и системный яп из них точно не > получился, зело уж сложные отношения у их нечто с рантаймом, стартапом > и прочим.Нет там рантайма, если разобраться и написать свой.) Диспетчер исключений это аналог setjmp.h. Статические конструкторы это аналог __init. typeinfo не обязательно использовать, да и реализация уложится в сотню строк. >> Именно это много лет как решает Си++ с std::unique_ptr. > 1) В ядре/бутлоадере/фирмвари и т.п. в общем случае НЕТ stdlib. unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой } транслятор вставляет free(ptr); >> Фирмварь работает где-то далеко > У меня она "на кончиках пальцев". Вон, в терминалке со мной через > подобие ROM-монитора чатится. Накодив работу с шаговиком - погонять его интерактивно > туда-сюда с разными скоростями и числами шагов было намного прикольнее любых > бсодов. Управление шаговиком в стиле Quake с клавы? Ну нет смысла её ронять, в отличие от живой сиситемы, по по пальцам она не ударит и рефлекс не выработается. >> и там ошибка страницы не так наглядна, как на живой системе. > Там нет страниц, поэтому нет и ошибок страниц. И вы же не > думаете что я буду ронять себе основную систему при ядерных экспериментах? > Это сейчас все нормальные люди в виртуалках делают. На эту тему есть анекдот: - почему ты забыл префикс lock? - у меня на вируталке и так работает! >> Никто не хочет, что бы что-то валилось. В 19-м веке, когда принимали мост, >> ставили инженеров под него и сверху пускали паровоз. > Мне эта идея нравится и я хочу дойти до состояния когда я > реально не зассу полагаться на мои фирмвари даже зная что их > отказы могут меня угробить. А просто надо не ссать. Опыт приходит сразу после того как был нужен. :)
- YOU are full of Bullshit!, Аноним, 23:51 , 30-Июн-22 (518)
- YOU are full of Bullshit!, n00by, 10:18 , 01-Июл-22 (526)
>> Диспетчер исключений это аналог setjmp.h. > Я не уверен что в ядре исключения хорошая идея.Потому и пишу "аналоги". Оно как бы есть по стандартам языков, но вполне можно без него. > И хрустиковая паника > тоже. Ну вот допустим у нас не получилось выделить память а > падать не хотим. Вместо этого хотим попозже попытаться опять. Но исключения > и паника это не обеспечат. В Си++ это всё делается с помощью placement new, либо точно так же как и в Си. > Торвальц хрустикам популярно донес, до них > дошло вроде. И будет у них там более сиобразный стиль... ))) Только в другом синтаксисе. >> Статические конструкторы это аналог __init. > Этот __init что и где? В сях его быть не обязано, технически > гнутый тулчайн оперирует entry (с любым названием). Этот __init можно найти в коде ядра. Точно так и статические экземпляры не обязательно создавать. > Его вызывают (кто и > почему отдельный вопрос), а дальше - теоретически, там должен быть стартап, > который нормальную сишную арену соберет. В стандартной программе потом main вызовет. > Может быть и что-то еще, тогда это окружение отличается от стандартного > си по свойствам. Сам компилер в freestanding режиме как максимум может > хотеть 3 функции, это 100% документировано: memcpy, memset и memmove. Вот > их он реально иногда сам втыкает при кодогенерации. У плюсоы все > сильно разлапистее, конечно. У меня это всё практически написано в виде работающего кода. Потому я могу утверждать, что мнение "сильно разлапистее" является предрассудком, в лучшем случае после знакомства с жирными реализациями. Это примерно как сказать "Си не годится в ядро, поскольку glibc много весит". ;) >> unique_ptr не требует что-либо из "рантайма". Упрощённо можно считать, что перед скобкой >> } транслятор вставляет free(ptr); > Круто, кроме того что alloc/free изначально тоже нет. Их как максимум можно > себе создать. Потому и написано "упрощенно". Вызывается заданная программистом функций. >> - почему ты забыл префикс lock? >> - у меня на вируталке и так работает! > А таки я активно VM юзаю, ядерщики тоже, и это сильно упрощает > многие вещи. И разницы с VM и железом обычно минимум. Да, "обычно минимум". То есть разница есть.
- YOU are full of Bullshit!, n00by, 13:14 , 23-Июн-22 (263)
И ещё я не понял, как найти твои коммиты в ядро. По фамилии из профиля не находит.
- YOU are full of Bullshit!, n00by, 09:04 , 24-Июн-22 (346)
Если же у тебя нет коммитов в ядро (согласно тамошних правил, следует указывать реальную фамилию), то возникает другой вопрос: если ты не имеешь отношения к разработке ядра, то какое твоё дело, что происходит в ядре? Вот это можешь объяснить? Не мне, себе объясни, для начала.
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 11:25 , 22-Июн-22 (37) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., DmA, 11:28 , 22-Июн-22 (38)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:40 , 22-Июн-22 (5) +13 [^]
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:44 , 22-Июн-22 (8) –24 [V]
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:52 , 22-Июн-22 (17) –2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 09:57 , 22-Июн-22 (23) –2
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 11:18 , 22-Июн-22 (36) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 11:55 , 22-Июн-22 (47) +5
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:08 , 22-Июн-22 (54) –2
- Линус Торвальдс не исключил возможность интеграции поддержки..., НяшМяш, 13:17 , 22-Июн-22 (109) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., InuYasha, 11:19 , 23-Июн-22 (257)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:31 , 26-Июн-22 (430)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 22:54 , 26-Июн-22 (480)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Cucumber, 12:33 , 22-Июн-22 (78) +3
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:38 , 22-Июн-22 (136)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 23:32 , 22-Июн-22 (225) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 10:25 , 23-Июн-22 (252)
> Тем временем C++ (орфография сохранена, ... - это именно троеточие, прямо в > коде) > template<class T, class... Args> > inline T& fn(Args&&... args) { Точнее, многоточие. Внезапно, в данном случае оказывается интутивно-понятно. Хотите "грузить" - налегайте на && и move semantics. Я бы уже загрузился. ;)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:13 , 23-Июн-22 (262)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 13:19 , 23-Июн-22 (265)
> Это код из реального проекта, который судя по всему пишут компетентные разработчики, > может поэтому и понятен.Не сочиняйте. Fn - это foo. > Но даже это кажется бессмысленной лапшой для > человека, котрый знаком с хорошими языками. "Интуитивно-понятно" в моём ответе выше следует понимать как "исходя из знания грамматики русского языка".
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:44 , 23-Июн-22 (272)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 15:59 , 23-Июн-22 (297)
> Не сочиняю, увидел вызов fn<X>(args) и стало интересно, что за лапша. Оно > мало того, что оказалось перегружено, так ещё и вот в такой > форме.В живом проекте кто-то назвал функцию fn? Это невозможно. > Нет, исходя только из грамматики русского языка, смысл этого кода понять не > получится. Пишите честно: "мне не удалось понять".
- Линус Торвальдс не исключил возможность интеграции поддержки..., Онаним, 08:59 , 23-Июн-22 (244) –1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 10:37 , 22-Июн-22 (26)
- Линус Торвальдс не исключил возможность интеграции поддержки..., microsoft, 10:57 , 22-Июн-22 (31) +10 [^]
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 11:09 , 22-Июн-22 (34) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Sw00p aka Jerom, 11:42 , 22-Июн-22 (40)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Bob, 11:57 , 22-Июн-22 (49)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:14 , 22-Июн-22 (61) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:19 , 22-Июн-22 (69) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:30 , 22-Июн-22 (76)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:41 , 22-Июн-22 (83) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 12:42 , 22-Июн-22 (85) –3
> Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического > алгоритма на чистом Си будет занимать меньше строк чем на Расте? Раст, внезапно, функциональный. Так что, в общем случае, меньше. Другое дело, что железо "императивно".
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 11:22 , 23-Июн-22 (258)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 12:43 , 23-Июн-22 (260)
>> Раст, внезапно, функциональный. > в расте функции - первоклассные объекты,Если верить Википедиям, то и Си++ они первоклассные https://en.wikipedia.org/wiki/First-class_function#Language_... > можно ими жонглировать как душе угодно? Он же компилируемый - так что есть нюансы с eval. Через пару лет можно будет оформить в виде llvm.ko. Зато "переменные" иммутабельны по умолчанию, не требуется императивный return. Вот обычные для ФЯ конструкции: let y = { let x = 3; x + 1 }; fn five() -> i32 { 5 } https://doc.rust-lang.org/book/ch03-03-how-functions-work.html Осталось прикрутить к этой безусловно полезной абстракции отображенные в память регистры контроллера...
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 15:00 , 23-Июн-22 (286)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 15:34 , 23-Июн-22 (291)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 16:25 , 23-Июн-22 (299)
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном > программировании не нужна.Смысл функционального программирования не в этих всех замыканиях. Если процедура хранит состояние, то для одних и тех же входных данных она может давать различный результат. Отсюда следует идея чистых функций и иммутабельности: если состояние не хранить, тогда можно на этапе трансляции доказать корректность кода -- как раз это в Rust и называют "безопасность". По той же причине в императивных языках по возможности стараются писать const. Но в реальном железе имеем const volatile. =)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:58 , 26-Июн-22 (442)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 16:07 , 23-Июн-22 (298)
>> Вот обычные для ФЯ конструкции: > Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций > и прочая ненизкая математика?Наберите интересующие слова в поисковике и читайте. Как должно быть понятно из первой ссылки, которую Вы заботливо вырезали при цитировании, там всё это можно найти. Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:40 , 26-Июн-22 (435)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 13:12 , 26-Июн-22 (447)
>> Он же компилируемый - так что есть нюансы с eval. Через пару >> лет можно будет оформить в виде llvm.ko. > Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет, > за это Торвальдс таки все же прилюдно люстрирует, имхо :) Так это будет потом. Когда привыкнут, что Rust уже и так есть, выйдет версия 2.0. Окно Овертона же.
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:07 , 22-Июн-22 (104)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 15:23 , 22-Июн-22 (149) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Андрей, 18:25 , 22-Июн-22 (173)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 03:08 , 23-Июн-22 (235) +4
- Линус Торвальдс не исключил возможность интеграции поддержки..., Sw00p aka Jerom, 22:15 , 23-Июн-22 (323)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 01:21 , 24-Июн-22 (330)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 07:50 , 24-Июн-22 (341)
> А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и > нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия > такая, секта? Может им приходилось принимать участие в разработке ядра? Если они знают Си, это вероятный сценарий. Если это так, значит часть "луддитов" говорит о том, что их так или иначе касается (насколько они правы или ошибаются - это вопрос второй). А вот что делают остальные?
- Линус Торвальдс не исключил возможность интеграции поддержки..., Sw00p aka Jerom, 13:57 , 24-Июн-22 (356)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:31 , 22-Июн-22 (77) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:45 , 22-Июн-22 (88)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:29 , 22-Июн-22 (129) +3
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 22:46 , 23-Июн-22 (326)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 07:55 , 24-Июн-22 (344)
Ядро Windows написано на Си, но исключения там используются. Механизм Structured Exception Handling (SEH) похож на Си++ исключения и последние могут быть реализованы поверх него. Штатный RTTI есть в Qt. Судя по возрасту проекта, когда-то там был свой велосипед, но теперь внутри него чистый dynamic_cast.
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 22:44 , 24-Июн-22 (373)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 07:43 , 25-Июн-22 (386)
> Про SEH я в курсе. Интересно именно про C++ и HaikuOS / > BeOS.Что именно интересно про Си++? Когда дизайнили ядро NT, насколько понимаю, языка С++ не было. SEH точно так же хранит некоторую информацию времени исполнения о типе ошибки. Точно так же есть проблемы, не работает на высоких IRQL. И ещё объекты ядра обмениваются сообщениями. :)
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 13:04 , 25-Июн-22 (393)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 15:48 , 25-Июн-22 (394)
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 16:17 , 25-Июн-22 (397)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 17:32 , 25-Июн-22 (399)
Я не вижу какого-либо конкретного вопроса в Ваших сообщениях. Возможно, потому что имею некторое представление, как работают диспетчер исключений и dynamic_cast. throw() это в моём понимании "с эксепшенами" (для kernel/slab/Slab.h сделано, как и должно быть). Их поддержку можно на уровне транслятора отключить.
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 19:09 , 25-Июн-22 (403)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 09:42 , 26-Июн-22 (417)
Напишу только по поводу MSVC (у GCC исходники открыты и всё должно быть документировано без меня). Если отключить RTTI, диспетчер исключений никуда не денется и будет выполнять свои задачи, вызывать деструкторы, искать и вызывать обработчик (подходящий окажется с ...). Его следует отключать отдельно, если поддержка исключений не нужна. А подход к написанию кода меняется уже от того, что код в ядре. В ряде случаев бросать исключения никак нельзя, будь то C++ или инструкция int3. И зачем в ядре dynamic_cast<>, где его можно применить, я пока не пойму.
- Линус Торвальдс не исключил возможность интеграции поддержки..., iPony129412, 12:42 , 22-Июн-22 (86) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:50 , 22-Июн-22 (91)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Иваня, 12:55 , 22-Июн-22 (97) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Без аргументов, 13:16 , 22-Июн-22 (108) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., НяшМяш, 13:20 , 22-Июн-22 (112)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:22 , 22-Июн-22 (113) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:35 , 22-Июн-22 (134)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 15:35 , 22-Июн-22 (151)
- Линус Торвальдс не исключил возможность интеграции поддержки..., _kp, 02:42 , 23-Июн-22 (232) +3
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:23 , 23-Июн-22 (267) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 13:38 , 23-Июн-22 (271) +1
В С89 объявление переменных было как в Паскале. При этом вложенных процедур там не было, потому и сняли ограничение. И речь тут про ядро, а не холивар языков. В Виндосе некоторые писали драйвера на Дельфи, потом, как правило, переписывали.
- Линус Торвальдс не исключил возможность интеграции поддержки..., _kp, 18:16 , 23-Июн-22 (308)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:11 , 28-Июн-22 (505)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 20:54 , 23-Июн-22 (316) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:45 , 26-Июн-22 (438)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:22 , 22-Июн-22 (114) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:23 , 22-Июн-22 (115) +6 [^]
- Линус Торвальдс не исключил возможность интеграции поддержки..., АнонимКо, 13:52 , 22-Июн-22 (119)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:34 , 22-Июн-22 (132)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 20:13 , 22-Июн-22 (196) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Ан, 21:22 , 22-Июн-22 (203) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 23:06 , 22-Июн-22 (217) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 15:00 , 22-Июн-22 (143)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Без аргументов, 15:49 , 22-Июн-22 (152) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:39 , 23-Июн-22 (282)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:42 , 23-Июн-22 (284)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 02:17 , 24-Июн-22 (332) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анончик, 14:23 , 24-Июн-22 (357) +4
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анончик, 20:06 , 24-Июн-22 (363)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 21:01 , 24-Июн-22 (368) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анончик, 21:33 , 24-Июн-22 (370) –1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 10:59 , 25-Июн-22 (390)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 13:13 , 26-Июн-22 (448)
- Линус Торвальдс не исключил возможность интеграции поддержки..., bOOster, 12:12 , 04-Июл-22 (529)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:45 , 22-Июн-22 (180) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., АнонимГоним, 15:52 , 22-Июн-22 (153)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 16:01 , 22-Июн-22 (154)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 16:07 , 22-Июн-22 (155)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 17:22 , 22-Июн-22 (164)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:59 , 22-Июн-22 (185) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 02:24 , 24-Июн-22 (333) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 20:32 , 24-Июн-22 (364) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 23:10 , 24-Июн-22 (374) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 07:29 , 25-Июн-22 (385) +1
> Обязательная инициализация означает необходимость тратить время процессора и память на > ненужную оптимизацию переменных.Если переменная в памяти, память "потрачена" независимо от инициализации. Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения, т.е. в общем случае работать будет быстрее. > Для системного программирования, где важен каждый такт, > она неприемлема.
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 12:49 , 26-Июн-22 (440)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 13:37 , 26-Июн-22 (457)
>> Если переменная в памяти, память "потрачена" независимо от инициализации. > А вот это - совсем не факт. Оптимизатор может все пох@рить в > ноль если видит что side effects от этого ровно ноль. И > кода не будет вообще. И данных тоже. С железным аргументом "а > если не видно разницы, зачем генерить больше?" Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает необходимость тратить время процессора и память на ненужную оптимизацию переменных". >> Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения, >> т.е. в общем случае работать будет быстрее. > С чего бы это вдруг такие гарантии вот так безаппеляционно? Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе придётся ждать.
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 00:09 , 01-Июл-22 (520)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 10:28 , 01-Июл-22 (527)
>> Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет >> прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, >> тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе >> придётся ждать. > У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой. Это всё субъективно. Вон то про кеш - оно не зависит от наших убеждений. То есть инициализация переменных оправдана, как оптимизация по скорости. :)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 11:36 , 29-Июн-22 (511)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 17:45 , 22-Июн-22 (166) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 17:51 , 22-Июн-22 (167) +4
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:23 , 22-Июн-22 (171) –1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Андрей, 18:33 , 22-Июн-22 (175) +3
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 19:11 , 22-Июн-22 (188) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 21:21 , 22-Июн-22 (202)
- Линус Торвальдс не исключил возможность интеграции поддержки..., ilowry, 22:12 , 22-Июн-22 (207) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 11:16 , 23-Июн-22 (256)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 15:28 , 23-Июн-22 (290) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 19:08 , 23-Июн-22 (310)
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 23:33 , 23-Июн-22 (328)
- Линус Торвальдс не исключил возможность интеграции поддержки..., yet another anonymous, 00:00 , 24-Июн-22 (329) +2
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 02:54 , 24-Июн-22 (335)
- Линус Торвальдс не исключил возможность интеграции поддержки..., yet another anonymous, 07:47 , 24-Июн-22 (340)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 10:19 , 24-Июн-22 (350) –1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:35 , 24-Июн-22 (359) –1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анончик, 14:48 , 24-Июн-22 (360)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 21:10 , 24-Июн-22 (369)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анончик, 21:37 , 24-Июн-22 (371)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 22:35 , 24-Июн-22 (372)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анлним, 18:53 , 25-Июн-22 (401)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 20:03 , 25-Июн-22 (407)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 19:47 , 27-Июн-22 (499)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 02:05 , 29-Июн-22 (508)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 00:13 , 01-Июл-22 (522)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 00:51 , 01-Июл-22 (525)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 17:49 , 05-Окт-22 (531)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 23:27 , 24-Июн-22 (375)
- Линус Торвальдс не исключил возможность интеграции поддержки..., yet another anonymous, 23:50 , 24-Июн-22 (376)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 00:03 , 25-Июн-22 (377)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 03:44 , 25-Июн-22 (382) –1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анлним, 19:19 , 25-Июн-22 (404)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анлним, 19:44 , 25-Июн-22 (406)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 20:14 , 25-Июн-22 (408)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анлним, 20:41 , 25-Июн-22 (410)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 21:59 , 25-Июн-22 (413)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 11:13 , 26-Июн-22 (423)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 13:17 , 26-Июн-22 (453)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 19:52 , 26-Июн-22 (477)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анлним, 21:03 , 25-Июн-22 (411)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 22:06 , 25-Июн-22 (414)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 10:49 , 26-Июн-22 (422)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 12:28 , 26-Июн-22 (427) +1
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 19:34 , 26-Июн-22 (476)
- Линус Торвальдс не исключил возможность интеграции поддержки..., warlock66613, 20:14 , 26-Июн-22 (479)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:13 , 27-Июн-22 (495)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:31 , 27-Июн-22 (496)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:48 , 27-Июн-22 (498)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 10:36 , 26-Июн-22 (421)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:40 , 27-Июн-22 (497)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анлним, 18:28 , 25-Июн-22 (400)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 19:39 , 25-Июн-22 (405)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Анлним, 20:17 , 25-Июн-22 (409)
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 21:51 , 25-Июн-22 (412)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 10:19 , 26-Июн-22 (418)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 10:33 , 26-Июн-22 (419)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 10:34 , 26-Июн-22 (420)
Clear Interrupt Flag (cli)Operation 0 → IF Description Clears the interrupt flag if the current privilege level is at least as privileged as IOPL; affects no other flags. External interrupts disabled at the end of the cli instruction or from that point on until the interrupt flag is set
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 12:05 , 26-Июн-22 (424)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 13:16 , 26-Июн-22 (450)
> Я тоже умею копипастить и знаю, что делает инструкция cli.Я это не заметил в "Мамой клянусь, эта функция только X86_64.State меняет!".
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 13:40 , 26-Июн-22 (458)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 14:13 , 26-Июн-22 (460)
Я своими опилками не догоняю, как и что можно верифицировать в запрете прерываний. Посмотреть далее наличие Hlt и убедиться, что инициализируется Application Processor? У меня прям дымиться начинают опилки от этих мыслей.
- Линус Торвальдс не исключил возможность интеграции поддержки..., burjui, 14:31 , 26-Июн-22 (461)
- Линус Торвальдс не исключил возможность интеграции поддержки..., n00by, 16:05 , 26-Июн-22 (464)
Возможно дело в том, что ты пытаешься везде разглядеть атаки на Rust. На само деле, мне интересна именно эта команда. Ты писал когда-нибудь команду cli? Если да, то зачем?
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 18:30 , 26-Июн-22 (474)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 19:01 , 26-Июн-22 (475)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Аноним, 14:25 , 27-Июн-22 (483)
- Линус Торвальдс не исключил возможность интеграции поддержки..., qsdg, 11:50 , 28-Июн-22 (504)
- Линус Торвальдс не исключил возможность интеграции поддержки..., Fedd, 13:11 , 29-Июн-22 (513)
- Линус Торвальдс не исключил возможность интеграции поддержки..., adolfus, 17:02 , 30-Июн-22 (516)
|