The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%

03.01.2022 10:46

Инго Молнар (Ingo Molnar), известный разработчик ядра Linux и автор планировщика задач CFS (Completely Fair Scheduler), предложил для обсуждения в списке рассылки разработчиков ядра Linux серию патчей, затрагивающих более половины всех файлов в исходных текстах ядра и обеспечивающих увеличение скорости полной пересборки ядра на 50-80% в зависимости от настроек. Реализованная оптимизация примечательна тем, что она сопряжена с добавлением самого крупного в истории разработки ядра набора изменений - для включения разом предложено 2297 патчей, меняющих более 25 тысяч файлов (10 тысяч заголовочных файлов в каталогах "include/" и "arch/*/include/" и 15 тысяч файлов с исходными текстами).

Прирост производительности достигается за счёт изменения метода обработки заголовочных файлов. Отмечается, что за тридцать лет разработки ядра состояние заголовочных файлов приняло удручающий вид из-за наличия большого числа перекрёстных зависимостей между файлами. Работа над реструктуризацией заголовочных файлов заняла более года и потребовала проведения значительной переработки иерархии и зависимостей. В ходе реструктуризации была выполнена работа по разделению определений типов и API для разных подсистем ядра.

Среди внесённых изменений: отделение высокоуровневых заголовочных файлов друг от друга, исключение связывающих заголовочные файлы inline-функций, выделение заголовочных файлов для типов и API, обеспечение обособленной сборки заголовочных файлов (около 80 файлов имели мешающие сборке непрямые зависимости, выставляемые через другие заголовочные файлы), автоматическое добавление зависимостей к файлам ".h" и ".c", пошаговая оптимизация заголовочных файлов, использование режима "CONFIG_KALLSYMS_FAST=y", выборочная консолидация Си-файлов в сборочные блоки для снижения числа объектных файлов.

В итоге, проделанная работа позволила на 1-2 порядка сократить размер заголовочных файлов, обрабатываемых на стадии после препроцессинга. Например, до оптимизации использование заголовочного файла "linux/gfp.h" приводило к добавлению 13543 строк кода и подключения 303 зависимых заголовочных файлов, а после оптимизации размер сократился до 181 строк и 26 зависимых файлов. Или другой пример: при препроцессинге файла "kernel/pid.c" без патча подключается 94 тысяч строк кода, большая часть которого не используется в pid.c. Разделение заголовочных файлов позволило снизить объем обрабатываемого кода в три раза, сократив число обрабатываемых строк до 36 тысяч.

При полной пересборке ядра командой "make -j96 vmlinux" на тестовой системе применение патчей показало сокращение времени сборки ветки v5.16-rc7 с 231.34 до 129.97 секунд (с 15.5 до 27.7 сборки в час), а также повысило эффективность использования ядер CPU во время сборки. При инкрементальной сборке эффект от оптимизации ещё более заметен: время повторной пересборки ядра после внесения изменений в заголовочные файлы сократилось в разы (от 112% до 173% в зависимости от изменяемого заголовочного файла). Оптимизации пока доступны только для архитектур ARM64, MIPS, Sparc и x86 (32- и 64-бит).

  1. Главная ссылка к новости (https://lwn.net/Articles/88017...)
  2. OpenNews: Линус Торвальдс поднял вопрос целесообразности расширенной защиты от Spectre v2
  3. OpenNews: Анализ тенденций и участников разработки ядра Linux
  4. OpenNews: Автор CFS провел исследование производительности планировщика задач BFS
  5. OpenNews: Инициатива по устранению глобальных блокировок в Linux ядре
  6. OpenNews: Проект по задействованию LTO-оптимизации при сборке ядра Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/56449-kernel
Ключевые слова: kernel, linux, compile, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (399) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Онаним (?), 11:12, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +99 +/
    Титанический труд, да...
    Очень надеюсь, что с принятием такового затягиваться не будет, потому что иначе всю работу придётся проделать второй раз.
     
     
  • 2.11, макпыф (ok), 11:39, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +11 +/
    скорее всего будут, так как проверить это все не так быстро. Придется ждать ревью от маинтейнеров всех затронутых подсистем и т.д.
     
     
  • 3.58, Кирилл (??), 12:58, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +9 +/
    И это первый шаг.
    Когда разгреб первую гору навоза. Выльется ещё 10.
    А раньше эти 10 не замечали.
    Так как кто раньше уходил разгребать - не возвращался.
    Эффект выжившего.
    Теперь главное что сам линтер был написан высокоуровнево. И сам не превратился в дракона с золотыми цепями совместимости.
     
  • 2.50, анончик (?), 12:47, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Согласен, - чувак просто монстр!!!
    p\s Когда изучал libc, в частности picolibc, тоже обратил внимание, что там бардак с заголовками,
    + туева куча одинаковых макросов, по хорошему место которым в одном файле. Решил начать всё это рефакторить, но интузиазм быстро пропал:( - за бесплатно таким заниматься такое себе удовольствие:))
    p\p\s вот что бывает когда, весь проект это по сути этакий копи-паст из других проектов, или когда нет четкого стиля для проекта, - да там, даже в одной функции можно было увидеть, что она была составлена из кусков которые писали разные люди:)))
     
  • 2.89, Аноним (89), 13:53, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –14 +/
    Конечно примут. Это же кого надо патчи.
     
     
  • 3.102, опеннетовский анон (?), 14:47, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +6 +/
    А что, вы отправляли патчи, и их не принимали? Расскажите подробнее.
     
     
  • 4.186, Аноним (186), 22:34, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –6 +/
    reiser4?
     
  • 4.198, Аноним (89), 23:59, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Тебя простить может только что ты лежал в криосне. И сейчас пробудился. Потмоу что через один новость на опеннете о том как приняли или не приняли очередной патч. Вот Инго упоминаемый тут в ядро внес вклад.  А вот Кон не внес. Рядом рассказывают как принимают ксмбд. А недалеко уже неизвестно какой раз пытаются бить на патчи автор ваергварда. Тут же недалеко всё что было до селинуха отправили лесом. И прочая, прочая. Ты на самом деле не в курсе как это происходит уже пару десятков лет?
    А у комментария ещё есть прекрасный маркерок. Уровень деградации опеннетчиков.
     
     
  • 5.281, Michael Shigorin с дороги (?), 17:57, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Деградация -- это когда пытаешься судить о чём-то исключительно со слов рабиновича, музыки рабиновича?..

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

    О том, что со сложными патчсетами нетривиальные люди могут годами стучаться (до того вложившись в их наработку) -- разумеется, тоже знаю.  Но то же ГОСТовское шифрование в ядро коллеги (точнее, vt@altlinux) вполне себе дотащили.

     
     
  • 6.322, Аноним (89), 10:10, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно рабиновичи мне напели. Миша уж кому-кому а тебе бы по этому поводу не говорить. Как там етцнет, втянули во все ведущие дистры? Как там кастэл с рсбаком что вы собирали, успешно применен в ядре и дистрах? Все патчи с рпм альтового уже втянули в апстрим? Как там опенволовские патчики, приняты безоговорочно? А рядом, например, ваергвард который порвали на куски и впихнули непойми как в ядро.

    >   Но то же ГОСТовское шифрование в ядро коллеги (точнее, vt@altlinux) вполне себе дотащили.

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

     
     
  • 7.401, IRASoldier_registered (ok), 16:40, 07/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Гляди-ка, нашелся конспиролог круче Шигорина, хотя казалось бы, куда уж круче-то.
     
     
  • 8.408, Аноним (89), 04:32, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А лгать прилюдно не стыдно Простые факты доступные для проверки всем называть к... текст свёрнут, показать
     
     
  • 9.437, IRASoldier_registered (ok), 01:31, 23/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    веры всем конспирологам Поправил, не благодари ... текст свёрнут, показать
     
  • 2.172, Ordu (ok), 21:04, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Очень надеюсь, что с принятием такового затягиваться не будет,

    Будут. В описании патчсета Инго настойчиво повторяет, что это RFC, то есть request for comments от сообщества. И его дальнейшие планы на тот случай, если в целом linux выскажет готовность пойти на принятие такого -- это допиливать сие в отдельном дереве, с тем чтобы основную часть работы выполнить до мерга в мейнстрим, оставив на потом лишь ловлю блох.

    > потому что иначе всю работу придётся проделать второй раз.

    Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. Что требует конечно времени, но существенно меньше, чем можно было бы подумать. Во-вторых, есть шансы, что сейчас кто-нибудь подключится, и, допустим, пока Инго продолжает выпиливать, кто-то другой будет заниматься rebase'ами.

     
     
  • 3.232, qux (ok), 13:01, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. Что
    > требует конечно времени, но существенно меньше, чем можно было бы подумать.

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

     
  • 3.334, Аноним (334), 13:10, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты.

    Это ядро. Тут патчи принято приводить к нужному виду, а не коммиты таскать. Сейчас в отдельной ветке проведут ревью (уже обговорили в рассылке), протестят, подправят, оформят новым набором патчей с меньшим их числом (автор уже сказал что 70% можно в один).

     
     
  • 4.335, Ordu (ok), 13:21, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты.
    > Это ядро. Тут патчи принято приводить к нужному виду, а не коммиты
    > таскать.

    Коммиты и есть патчи, только хранимые в git.

     
     
  • 5.376, Аноним (334), 21:04, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Коммиты и есть патчи, только хранимые в git.

    Удивительно. Только прежде чем их примут в ядро, ты десять раз переделаешь их. Именно переделаешь, а не добавишь ещё несколько коммитов.

     
     
  • 6.377, Ordu (ok), 23:32, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Коммиты и есть патчи, только хранимые в git.
    > Удивительно. Только прежде чем их примут в ядро, ты десять раз переделаешь
    > их. Именно переделаешь, а не добавишь ещё несколько коммитов.

    И чё?

     
  • 2.204, Семен (??), 05:07, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скорее всего затянется. Мне чтобы заставить работать этот набор патчей пришлось написать еще несколько своих патчей. Плюс ядро у меня ловило кернелпаник.
     
  • 2.315, pavlinux (ok), 05:18, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ....
     
  • 2.398, жорик (?), 21:16, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    я руками собираю
     

  • 1.2, Аноним (2), 11:17, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –14 +/
    Почему сишники за 50 лет не догадались сделать модульную систему как в Яве? Каждый компиляйшон юнит требует парсинга сто шессот файлов. В каком нибудь Дельфи жмещь запустить - и сразу запускается
     
     
  • 2.14, Онаним (?), 11:44, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Сразу видно, что серьёзных проектов на Дельфи у тебя не было :D
     
  • 2.17, Аноним (17), 11:50, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Потому, Delphi компиляет отдельные юниты в отдельные независимые модули (которые даже если и лежат в итоге в одном бинарнике - по сути, как набор отдельных взаимодействующих библиотек). А "Ява" - это вообще виртуальная машина, у неё вообще никаких гарантий на время выполнения нет. Одна и та же строчка кода может работать как 1, так и 1000 единиц времени.

    В случае с Си, из-за того, что язык используется для системного программирования - требуются гарантии детерминированности времени исполнения кода. И если Delphi программа может позволить себе "подождать" несколько миллисекунд на то, чтобы подгрузить страницы другого модуля, инициализировать его и т.д., то если у тебя в обработчике прерывания в ядре начнёт происходить недетерминированная хрень и логика-отсебятина компилятора - то ядро просто работать не будет.

    В си тоже вполне себе есть "модули". Библиотеки (статические и динамические) - это именно про это. Если ты разбиваешь свой проект на отдельные незавимые библиотеки - то чаще всего их можно собирать
    и редактировать каждый по отдельности, и пересборка всего проекта не требуется. И даже ядро умеет динамически линковаться с кодом - kernel objects - это именно про это. Просто из-за особенностей ядерной разработки - одна правка в базовое ядро может сломать модули, собранные под старое ядро, причём самым неожиданным образом (т.к. всё работает в одном адресном пространстве, промахнулся на 1 байт в структуре - и ты уже, например, корраптишь данные файловой системы). Поэтому дешевле не портить себе нервную систему и не стрелять в ногу - так что ядро пересобирают целиком.

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

     
     
  • 3.22, Цезий Родонович (?), 12:01, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Что за дичь ты написал? Особенно доставило про делфи и инициализацию модулей.
    Некоторые недостатки других ЯП и компиляторов, никак не оправдывают конченную модульность в C/C++
     
     
  • 4.34, Аноним (17), 12:14, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что это именно так и устроено - каждый дельфёвый модуль - это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой набор функций и использует функции других библиотек. Т.е. ничем концептуально не отличается от проекта на си, состоящего из нескольких десятков статически слинкованных библиотек. Когда пишешь на C - тебе не приходится пересобирать каждый раз glibc с проектом.

    На сях обычно каждый C-файл не делают отдельной библиотекой. Во-первых, потому что растут накладные расходы, софт становится медленнее. А во-вторых, это закрывает целый ряд оптимизаций, который возможен в gcc (в том числе link-time optimization), но не возможен в Delphi, потому что МОДУЛЬНОСТЬ.

     
     
  • 5.42, iZEN (ok), 12:26, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Приходится из-за детерминированности связей с обратными вызовами и LTO В класси... большой текст свёрнут, показать
     
     
  • 6.65, Аноним (65), 13:20, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А теперь пойди и посмотри на классический трупопаскаль, ага. Один раз, а потом второй, но уже глазами
     
  • 3.23, Цезий Родонович (?), 12:01, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Что за дичь ты написал? Особенно доставило про делфи и инициализацию модулей.
    Некоторые недостатки других ЯП и компиляторов, никак не оправдывают конченную модульность в C/C++
     
     
  • 4.94, Аноним (-), 14:09, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >C/C++

    Это что за язык такой?

     
     
  • 5.122, Аноним (122), 16:27, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Он даже не в курсе, что это два разных языка. Просто второй скопипастил у первого, но как-то не очень уверенно и криво. Даже разные фишки выкидывать пришлось ради "святого ООП", который по факту просто макрос для вызова функций с контекстом (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях).
     
     
  • 6.135, Аноним (-), 17:01, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > restrict появился в c99
    > (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях).

    Экспердус опеннетус вульгарис ...


     
  • 5.228, Аноним (228), 11:58, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это два языка. Никогда не видел перечисление косой чертой?
     
     
  • 6.290, Аноним (-), 18:32, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    В Юникс мире такого перечисления никто не знает.
     
  • 3.24, Аноним (2), 12:02, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > закидывают всё в один проект и делают монолитные проекты на 60 миллионов строк кода которые компиляются в районе суток

    Ну зайди в билд систему любого дистра и убедись, что неоправданно долгая компилюха - это болезнь вообще всех сишных проектов. Перейдя в Линукс, в свое время удивился, как обычный gtk.-хелловорлд компилился секунды, а не наносекунды, как в Дельфи.

     
     
  • 4.39, Аноним (17), 12:22, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я гентушник, мне не надо "заходить в билд систему", она у меня прямо на компе.

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

     
     
  • 5.48, Аноним (2), 12:38, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > проблема рук, растущих не из того места, а не языка.

    Следовательно, таки языка, а не рук.

     
  • 4.412, n00by (ok), 19:57, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А если бы хоть раз посмотрели машинный код после кодогенератора Дельфи, то удивления бы не было.
     
  • 3.416, A.N.Onimous (?), 23:17, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >из-за особенностей ядерной разработки

    Интересный эвфемизм для отсутствия архитектуры

     
  • 2.18, Аноним (18), 11:51, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ява же любит кушать память
     
     
  • 3.37, iZEN (ok), 12:16, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –7 +/
    > Ява же любит кушать память

    Пальму первенства по этому свойству она давно отдала Rust'у.


     
     
  • 4.86, Rev (?), 13:48, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    А будут ссылки на доказательства, или ты просто балабол?
     
     
  • 5.96, Аноним (96), 14:16, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Из книжки Rust:
    Гарантии безопасности памяти в Rust затрудняют, но не делают невозможным случайное выделения памяти, которая никогда не очищается (что известно как утечка памяти ). Полное предотвращение утечек памяти не гарантируется Rust, так же как не является гарантией отсутствие гонок данных проверенных во время компиляции, а это означает, что утечки памяти безопасны в Rust.

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

     
     
  • 6.159, kai3341 (ok), 18:37, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Давай переведу с русского на русский: разработчики Rust предупреждают, что говнокод может течь -- какая неожиданность
     
     
  • 7.171, pda (ok), 21:03, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Подождите, этот гений однажды узнает, что в Java несмотря на gc тоже возможны утечки памяти, его тогда инфаркт хватит...
    https://www.baeldung.com/java-memory-leaks
     
  • 7.230, aname (?), 12:43, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так а зачем нам такой безопасный язык- то?
     
     
  • 8.253, Аноним (253), 15:30, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Затем что невозможно избежать утечек памяти Это как пытаться избежать языковыми... текст свёрнут, показать
     
     
  • 9.286, Аноним (286), 18:06, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда и не надо было пыжиться, пытаясь заменить C , Rust отличная замена сишарп... текст свёрнут, показать
     
     
  • 10.307, Аноним (253), 21:45, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сишарп на виртуальной машине работает Его сравнивать с Rust C C некорректно, ... текст свёрнут, показать
     
     
  • 11.325, Онаним (?), 11:31, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На данный момент он да, избавляет от 99 эксплуатируемых уязвимостей, просто пот... текст свёрнут, показать
     
     
  • 12.348, DyadyushkaAU (ok), 14:14, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В твоём г-нокоде - вполне возможно Google, MS, Huawei, Mozilla, Amazon - уже эк... текст свёрнут, показать
     
  • 7.283, Аноним (286), 18:00, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >разработчики Rust предупреждают, что

    сборка мусора не работает и надо использовать костыли, а криков-то по поводу free() было...

     
     
  • 8.308, Аноним (253), 21:47, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Каким образом выход за скоуп объекта с его немедленным освобождением является ко... текст свёрнут, показать
     
  • 7.431, Аноним (431), 07:20, 12/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >разработчики Rust предупреждают, что говнокод может течь

    На Rust бывает другой код?

     
     
  • 8.432, Аноним (-), 14:29, 12/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У тебя нет, независимо от ЯП Но не все люди - ты ... текст свёрнут, показать
     
  • 4.93, lufog (ok), 14:08, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сомнительное утверждение, учитывая что в Rust нет сборщика мусора, а ресурсы освобождаются автоматически при выходе переменной из области видимости. В теории, конечно можно оперировать сырыми указателями в unsafe блоке, и управлять памятью вручную, но это ничем не будет отличаться от того же C/C++.
     
     
  • 5.413, n00by (ok), 20:05, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Удивительно, но free() не обязательно освобождает ресурсы, а всего лишь возвращает память куче. Потому, когда на "том же же C/C++" пишут специфичные для задачи менеджеры памяти, которые решают проблему фрагментации кучи, "автоматическое освобождение" течёт. А когда все переменные стековые, то получается максимум HelloWorld.
     
  • 3.46, Аноним (46), 12:33, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Когда на любой чих делают аллокацию объекта, да еще и в цикле, а потом ява виновата, а не криворукие кодеры.
    В джаве так-то можно JVM указать, сколько хипа она максимально может выжрать, прежде чем с ООМ грохнется.
     
     
  • 4.170, лютый жабби__ (?), 21:03, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >В джаве так-то можно JVM указать, сколько хипа она максимально может выжрать

    и как это опровергает фразу "жаба жрёт ОЗУ как свинья помои"? Погугли сколько памяти в жабе занимает Double или Integer )

    И, кстати, делать 100500 одноразовых иммутабельных объектов (и массово заниматься их копированием с места на место) - это прямая рекомендация от корифеев многопоточного погромирования на жабе )

     
     
  • 5.357, Аноним (46), 14:50, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Иммутабельность позволяет получить дешевую в поддержке потокобезопасность. Никто не пойдет ковыряться в проекте, где мьютекс на мьютексе и семафором погоняет. Ну может за ОЧЕНЬ большие деньги. А так как у иммутабельных объектов нет стейта, их можно закешировать в пул и возвращать одну и ту же сцыль. Так что все проблемы с аллокацией снова от криворуких кодеров, не могущих в педантичное переиспользование того, что можно переиспользовать. Про Flyweight паттерн еще GoF писали.
    P.S. А классы-обертки везде использовать тебя никто не заставляет.
    "Нормально делай - нормально будет." (с)
     
  • 2.27, Аноним (27), 12:07, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тем временем не только лишь каждый Java проект размером на 3 порядка меньше собирается быстрее, чем за 130с.
     
     
  • 3.153, Аноним (153), 18:04, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Настоящий Java проект только на скачивание артифактов трати больше чем 120 сек
     
     
  • 4.193, мое правило (?), 23:25, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У нас серверок был, логики не очень много и полностью кастомная, на джава.

    И там были зависимости на апач либы разной бигдата направленности. И эта помойная параша без локального кеша с быстрого прокси в сети качала зависимости 1.5 часа. Оно писало сотни тысяч мелких и больших файликов, делало миллионы запросов на ьедное прокси. С локальным кешом собиралось 30 минут. Что бы не страдать во время локального девелопмента я на начале спринта регулярно запускал скрипт, который собирал свежие зависимости и хардкодом записывал их во все возможные анналы класспаса, и чистил зависимости. Таким образом сборка кода и артефактов для установки занимала 10 минут.

     
  • 2.35, Аноним (35), 12:15, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > В каком нибудь Дельфи жмещь запустить - и сразу запускается

    С Бейсиком не попутали?

     
     
  • 3.113, OpenEcho (?), 15:49, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да и не с каждым Бейсиком прокатит, Power Basic к примеру тоже компилировать сперва прийдется
     
  • 3.161, Аноним (161), 18:43, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кстати разработчики Delphi реально всегда выпячивали скорость компиляции, как главное преимущество над C++. Явное разделение интерфейса и имплементации позволяло делать очень быстрые однопроходные компиляторы.
     
     
  • 4.194, Аноним Максим (?), 23:26, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    На момент выхода Делфи скорость компиляции равноценных проектов переписанных с Си действительно отличалась на порядки, но это ж было аж на 386 процессорах и жесткими дисками даже без DMA.
    В то время и я писал на Делфи не смотря на паталогическое неприятие Паскаля.
    Логично, когда скорость компиляции Делфи на реальных проектах перестала быть ключевой особенностью, а среда разработки закостенела, тут от нее массово и отказались.
     
  • 2.52, Аноним (96), 12:52, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тормозное выполнение с гигабайтами памяти или тормозная сборка? что важнее конечному пользователю эклипса, андроида и прочих тормозных продуктов ява мира? Но на пользователей уже всем плевать, хренак хренак в продакшн и лишь бы побыстрее. потом просто сменим обои, кнопки - главное есть видимость улучшения.
     
  • 2.53, Аноним (53), 12:52, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Потому что, когда придумывали Си, не было гигабайтов памяти. И даже мегабайтов не было.
     
     
  • 3.56, iZEN (ok), 12:57, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Потому что, когда придумывали Си, не было гигабайтов памяти. И даже мегабайтов не было.

    Си придумали как заменитель ассемблера (который на каждой машине в 1970-х годах был свой), чтобы перенести Unix с одной машины (устаревающей не по дням, а по часам) на новую машину. "Быстро и грязно" — было в порядке вещей для C того времени.


     
     
  • 4.68, Аноним (68), 13:23, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    >"Быстро и грязно" — было в порядке вещей для C того времени.

    это и сейчас в порядке вещей, для всего

     
     
  • 5.231, DyadyushkaAU (ok), 13:00, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не надо преувеличивать. Может вы и не заметили, но некоторые вещи меняются к лучшему. Возьмём, к примеру, Rust. Там и модули есть, и с памятью работа корректная. Хотя некоторые программисты на Си к грязи настолько привыкли, что уже и не замечают, как они по макушку в ней увязли. Для них это уже естественное состояние. А потом появляются Геркулесы (наподобие того, что в новости) и пытаются хоть как-то расчистить то, что накопилось.
     
     
  • 6.238, Аноним (68), 13:37, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Возьмём, к примеру, Rust.

    Никто не преувеличивает. Раст мог выйти в 2030 году проработанным и стандартизированным, но такого хайпа он мог уже и не поднять и остался бы без поддержки.
    Но его сляпали быстро и грязно, а теперь постепенно допиливают. В каждой новой версии старая грязь остается во имя обратной совместимости.
    Спорить насколько "грязно", я не буду.

     
     
  • 7.366, DyadyushkaAU (ok), 16:04, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В каждой новой версии старая грязь остаётся только... в старой редакции. Другими словами, это настраиваемо, хочешь ли ты тащить эту грязь в свой новый проект (для какой-то обратной совместимости), или ограничишься свежайшей редакцией. Поэтому можно смело заявлять, в Rust НЕТ грязи.

    https://habr.com/ru/post/557460/

     
     
  • 8.380, Аноним (380), 00:11, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    вы каждый день начинаете новый проект Ваш проект тоже может быть сделан быст... текст свёрнут, показать
     
     
  • 9.383, DyadyushkaAU (ok), 13:17, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Причём здесь какой-то отдельной взятый проект В случае с C, C вы по умолчанию... большой текст свёрнут, показать
     
     
  • 10.389, Аноним (68), 17:08, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    не-а 8212 у меня лишь нет препятствий тащить о той, которую надо или переписы... большой текст свёрнут, показать
     
     
  • 11.390, DyadyushkaAU (ok), 17:53, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    О чём я и говорил ранее Программисты увязли по макушку в грязи, и этого не заме... большой текст свёрнут, показать
     
  • 2.72, fsb4000 (?), 13:31, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В С++ сделали модули. Лишь слегка медленнее чем fpc...
     
     
  • 3.160, kai3341 (ok), 18:42, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Точно сделали? Там модули год назад всё порывались принять в стандарт да не приняли. Дальше я не следил
    Или речь о динамически линкуемых библиотеках?
     
     
  • 4.183, fsb4000 (?), 21:44, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    модули приняли в С++20, а скоро уже С++23 выходит
     
     
  • 5.435, Аноним (435), 15:56, 15/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > модули приняли в С++20, а скоро уже С++23 выходит

    Ага. В таком виде, в котором они никому не уперлись.

    С includ'ами был одна проблема. При перекрестных вызовах методов из двух деревьев невозможно реализовать виртуальные методы возвращающие указатели нужного типа а не базовых.

    В модулях это было бы сделать можно, но !!!

    Эти, на всю голову больные люди, предусловием поставили отсутсвие перекрестых ссылок в модулях.

    Занавес!

     
  • 2.191, nc (ok), 23:21, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я понимаю, 50 лет назад были маленькие объемы оперативки А модульност... большой текст свёрнут, показать
     
     
  • 3.200, Ordu (ok), 00:16, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, как я понимаю, не подразумевает Если ты, компилируя модуль, будешь генериро... большой текст свёрнут, показать
     
  • 3.201, Аноним (201), 01:24, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это и так можно делать, достаточно не держать в инклюдах ничего кроме объявлений и порезать использование шаблонов. Но все равно не поможет, так как хотелось бы чтобы линкер пооптимизировал код между объектниками всякими LTO, PGO а может и BOLTом.
     
  • 2.375, Аноним (375), 19:36, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ява вообще тут не к месту переплетена, тут она работает как многие динамические языки лениво подгружая зависимости по мере необходимости.
    Когда есть обращение к классу, этот класс ищется в загрузчике классов (в памяти JVM), если не найден,  то он ищется в classpath. В том числе по этому "java тормозит", она лениво подгружается после холодного старта, а всякие программки на go и c стартуют практически моментально (когда не требуют загрузки ресурсов с дисков).
     

     ....большая нить свёрнута, показать (64)

  • 1.3, Аноним (3), 11:22, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Больше патчей для линукса всем пользователями линукса!
     
     
  • 2.40, Аноним (40), 12:23, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет нет! не надо нам патчей пиши лучше отличный безглючный код.И лучше на асемблере.
     
     
  • 3.209, Аноним (209), 08:20, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А сопровождать его (код на ассемблере) под каждую архитектуру, ты будешь?
     
     
  • 4.214, Аноним (40), 09:53, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да я буду сопровождать! Принимаю доллары фунты йены евро.А вы как думали за качественный код на ассемблере надо платить.Привыкли при комуннистах бесплатно.Очнитесь.
     

  • 1.4, BratishkaErik (ok), 11:23, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Аля гентушники
     
  • 1.5, iZEN (ok), 11:28, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –20 +/
    А всё от того, что в С/С++ нет МОДУЛЬНОСТИ языка Pascal.
     
     
  • 2.9, Ananima (?), 11:37, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –18 +/
    Уже есть, но ваш этот спагетти-Linux уже никто не будет в состоянии переписать. Его изначально надо было писать нормально, а там за него первый взялся уже аутист-социофоб в очках, поэтому ядро обречено быть таким монстром
     
     
  • 3.13, Schwonder Reismus (?), 11:41, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Другие варианты есть?
     
     
  • 4.44, iZEN (ok), 12:27, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Другие варианты есть?

    Микроядерность.


     
     
  • 5.69, Аноним (65), 13:24, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Смешно
     
     
  • 6.75, pofigist (?), 13:34, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Грустно. Микроядерность требует хорошего проектирования архитектуры, что невозможно в опенсорце
     
     
  • 7.84, Gogi (??), 13:47, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ну тык Танненбаум же читал курс лекций именно по микроядерности!! Трольвадс в это время на дзюдо ездил ш_т_о_л_е??
     
     
  • 8.199, pofigist (?), 00:10, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Какое дзюдо Видимо - за пивом и пиццей Проблема в том что на х86 тех лет - к... текст свёрнут, показать
     
     
  • 9.340, uis (ok), 13:52, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Hurd... текст свёрнут, показать
     
     
  • 10.361, pofigist (?), 15:37, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И Каковы итоги ... текст свёрнут, показать
     
  • 9.415, A.N.Onimous (?), 23:14, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    L4 Лайнокс можно оставить на какое-то время, как рантайм... текст свёрнут, показать
     
  • 9.433, Аноним (433), 20:58, 12/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И почему же дипломированный аноним до сих пор не утёр студенту-недоучке нос И... текст свёрнут, показать
     
  • 7.282, Michael Shigorin с дороги (?), 18:00, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну почему, возможно -- просто остаётся академическими упражнениями обычно.

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

    Потом бегают юные бздишники-джависты-велосипедисты и рассказывают всем про настоящиеъ серебряные пули :)

     
     
  • 8.320, pofigist (?), 09:22, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошо Назови мне грамотно спроектированное опенсоурс5ое решение И желательно ... текст свёрнут, показать
     
     
  • 9.321, Аноним (321), 09:33, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Postfix, nginx, PostgreSQL, Hadoop, почти всё связанное с кластерами ... текст свёрнут, показать
     
     
  • 10.323, pofigist (?), 10:26, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И где в этом списке грамотно спроектированные продукты ... текст свёрнут, показать
     
     
  • 11.425, uis (ok), 17:04, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и сиди на apache... текст свёрнут, показать
     
  • 9.414, n00by (ok), 20:46, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    STL Степанова и Ли ... текст свёрнут, показать
     
  • 5.227, iskrim (?), 11:58, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Моя ты лапочка, что же с тобой сделали
     
  • 3.119, qsdg (ok), 16:05, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так Линус же всегда сам говорил, что: "микроядро лучше чем его монолит. но монолитный линукс уже готов, а ваш юникс ещё на горизонте".

    Скорость разработки, как обычно.

     
     
  • 4.168, Аноним (168), 21:01, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    ты вообще понятия не имеешь о чем говоришь.
     
  • 2.12, Anonnnym (?), 11:41, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В C++ есть модули. С разморозкой Вас
     
     
  • 3.19, Ananima (?), 11:52, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В GCC с адовыми костылями включаются, в QtCreator'е они не появятся никогда, в Visual Studio у них не работает IntelliSense. Не нужно рассказывать о том, что не будет юзаться ещё очень долгое время. Новые проекты будут писАться на чём угодно, но только уже не на плюсах. Плюсы -- это легаси, пора это принять.
     
     
  • 4.124, Аноним (124), 16:39, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Народ, для чего вы постоянно выделяете букву "а" в слове "писáться", как будто из контекста не понятно о чём идёт речь?
     
     
  • 5.182, Аноним (182), 21:30, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    По той же причине, что и слово «бóльшее», где даже контекст не важен.
     
     
  • 6.192, Аноним (380), 23:24, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    видел такое насчет "большая", а вот про "большее" как-то не встречал.
     
  • 3.20, Enamel (ok), 11:53, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Формально есть, для галочки, но фактически хорошо, если к 2030 будет реально использоваться.

    1. Сейчас не все даже C++14/7 используют, не говоря уже о C++20.

    2. Поддержка основными компиляторами всё еще частичная со звёздочками:
    https://en.cppreference.com/w/cpp/compiler_support

    3. Пока большинство проектов перейдет на модули, пройдет очень много времени.

    4. Навсегда останется легаси, которое этого не сделает.

     
     
  • 4.341, uis (ok), 13:56, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    GCC впереди планеты всей, а рядом шланг
     
  • 3.221, Прохожий (??), 10:58, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А Линукс на C++ написан?
     
     
  • 4.243, Anonnnym (?), 14:19, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > А Линукс на C++ написан?

    Нет, но это не противоречит тому факту, что в C++ есть модули

     
     
  • 5.369, DyadyushkaAU (ok), 16:57, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Оно-то не противоречит, конечно. Только в контексте обсуждаемой новости - абсолютно бесполезное новшество для Линукса.
     
  • 2.123, Аноним (122), 16:35, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Моё ядро с подключаемыми в рантайме модулями передаёт вам привет. Так же, как и все dll-ки/so-шки. Или вы бредите идеей того, что в Си ничего нету и он не менялся с момента его создания? По такой логике питон — самый продвинутый ЯП, несмотря на то, что это просто навороченный калькулятор, у которого GIL — не баг, а фича, причём «невероятно полезная и крутая».
     
     
  • 3.141, Аноним (-), 17:13, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Моё ядро с подключаемыми в рантайме модулями передаёт вам привет. Так же,
    > как и все dll-ки/so-шки. Или вы бредите идеей того, что в
    > Си ничего нету и он не менялся с момента его создания?

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

    > По такой логике питон — самый продвинутый ЯП, несмотря на то, что это просто навороченный калькулятор, у которого GIL

    Спрыги на унылую демагогию — самый продвинутый навых экспертусов, несмотря на то, что это просто бессмысленное и беспощадное сотрясание клавиатуры.

     
     
  • 4.336, uis (ok), 13:36, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И с каких пор LTO стал костылём модульности
     

     ....большая нить свёрнута, показать (33)

  • 1.6, Аноним (6), 11:30, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    j96? дайте мне такую машину
     
     
  • 2.15, Онаним (?), 11:48, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    -j96 ныне - это ещё так себе машина, всего лишь 48 ядер и 2 треда, какой-нибудь EPYC 7643, или дуалка из младших эпиков/тредрипперов.

    Ныне даже несервеный Threadripper 3995WX - это -j128 :D
    А дуалка из эпиков может и -j256 оказаться.

     
     
  • 3.32, Аноним (40), 12:13, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –5 +/
    А вы пробовали затестит стабильность бинарника на выходе 100500 ядер.Думаю что нет.
     
     
  • 4.59, Аноним (46), 12:58, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если параллелизация на уровне Make, то со стабильностью ниче не будет (как повлияет на стабильность одновременная компиляция независимых исходников?). Реальные проблемы при сборке - это то, что сами Makefile-ы написаны отстойно, т.е. могут отсутствовать правила, указывающие правильную очередность сборки, в результате чего можно влет получить состояние гонки, когда с первой попытки не соберется, а со второй - вполне себе. Да и еще про закон Амдала забывать нельзя о теоретическом пределе ускорения при параллелизации.
     
     
  • 5.74, Аноним (40), 13:33, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я просто поднял тему про которую никто особо здесь не говорит не более Может я н... большой текст свёрнут, показать
     
     
  • 6.99, Аноним (46), 14:27, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тут нужно смотреть контекст. Спутники и ракеты - это дорого и жалко терять, поэтому софт для них должен быть математически(!) верифицирован. Линукс же и его стабильность особо не волнует в контексте того, что тебе просто нужна серверная ОС, которая будет крутить твой интернет-сервис. Поэтому ну ничего удивительного, что сделали статистический анализ зависимости количества багов от параллелизации и нашли корелляцию. Как бы правильно разрабатывать комплексные параллельные системы ОЧЕНЬ сложно. Тут как с управлением автомобилем - даже на небольшой скорости есть шанс погибнуть в ДТП, но при соблюдении ПДД, своевременном техническом обслуживании и использовании ремней (и рабочих подушках) этот шанс ощутимо снижается. Поэтому все пользуются автотранспортом, т.к. риски приемлемые.
     
     
  • 7.142, Криптоханыга (?), 17:20, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Поэтому все пользуются автотранспортом, т.к. риски приемлемые.

    И боятся летать на самолетах, где реальный риск ниже...

     
     
  • 8.205, Аноним (205), 05:46, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Звездёж статистический На км пути риск ниже На поездку выше и сильно... текст свёрнут, показать
     
     
  • 9.216, www2 (??), 10:13, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, ну да Именно поэтому, если происходит авария с каким-нибудь самолётом, о... большой текст свёрнут, показать
     
     
  • 10.246, pavlinux (ok), 14:35, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там даже не малая, а частная в основном 2-х местные пропеллерные или вертолёты ... текст свёрнут, показать
     
  • 10.289, Michael Shigorin с дороги (?), 18:13, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На http vz ru бывают сообщения и по авиа-, и по авто-, и по железнодорожным да... текст свёрнут, показать
     
     
  • 11.438, www2 (??), 09:54, 28/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    О том и речь, что автомобильные аварии случаются гораздо чаще и интересуют СМИ л... текст свёрнут, показать
     
  • 6.195, мое правило (?), 23:30, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Емм, что вы там собираете? А ниче такого, что нормальные компиляторы выдают одинаковый разультат(побитово) в бинарниках?
     
     
  • 7.248, pavlinux (ok), 14:42, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Емм, что вы там собираете? А ниче такого, что нормальные компиляторы выдают
    > одинаковый разультат(побитово) в бинарниках?

    Ну ты сам-то понял, что это коммент полного лoxа?

     
  • 6.262, keydon (ok), 17:02, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я тоже некоторое время поработал в шаражке запускающей спутники(внезапно даже успешно). Сильная бюрократия, слабая квалификация и бесконечноеь чинопочитание преобладающее над знаниями и умениями были на каждом шагу. В основном там работали либо маразматики 80+ лет, либо просиживатели штанов, либо студенты для строчки в трудовой. Толковые специалисты там не задерживались.
    Так что близость к спутникам, военной приемке и госаппарату в целом это скорее приговор чем повод для повышения авторитета.
    > Баги и странное поведение работы программ наблюдалось в итоге.

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

     
  • 6.285, Michael Shigorin с дороги (?), 18:05, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > недоконца
    > как не странно
    > не понятных

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

    А в тройке по русскому для начала, если по-честному.  И натянутой тройке -- по математике.

    Не кивай на других.  Не обобщай с умным видом того, в чём вообще не соображаешь.

    Начни с себя.

    А там и космос вытянем заново, и не только его.

     
  • 6.313, Ordu (ok), 01:41, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Может я недоконца обозначил проблему

    Определённо.

    > Это было исследование на предмет расспараллеливания кода при компиляции на 100500 процессоров и как это влияет на конечную стабильность работы программ после сборки и запуске на реальном оборудовании.

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

     
  • 6.337, uis (ok), 13:41, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Может это был distcc? Да, там бывают свои приколы
     
  • 5.249, pavlinux (ok), 14:44, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если параллелизация на уровне Make, то со стабильностью ниче не будет (как
    > повлияет на стабильность одновременная компиляция независимых исходников?).

    LTO, не, не слышал?  

    Линковка  a+b+c+d, это не тоже самое что (a+b) + (c+d) ... и вообще разное (a+d) + (b+c)

    > Реальные проблемы при сборке - это то, что сами Makefile-ы написаны отстойно,
    > т.е. могут отсутствовать правила, указывающие правильную очередность сборки, в результате
    > чего можно влет получить состояние гонки,

    Сцк, откуда вы все повыползали??!!! С онлайн курсов чтоль?  

    Race condition - это борьба за общий ресурс, make - это линейная приблуда.
    -j n - это тупа n форков со своими линейными списками.  

    > когда с первой попытки не соберется, а со второй - вполне себе.

     
     
  • 6.287, Michael Shigorin с дороги (?), 18:07, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Если параллелизация на уровне Make, то со стабильностью ниче не будет (как
    >> повлияет на стабильность одновременная компиляция независимых исходников?).
    > LTO, не, не слышал?

    Ставлю навскидку тыщу рублей, что описанное в #74 было без -flto со товарищи :)

     
  • 6.302, Аноним (53), 19:54, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Линковка  a+b+c+d, это не тоже самое что (a+b) + (c+d) ... и вообще разное (a+d) + (b+c)

    Как эт ты их так сгруппировал? Я так не умею, у меня линковщик все файлы разом хочет получить. Причём make ему даже аргументы всегда в одном и том порядке подставляет независимо от -j.

     
  • 6.312, Аноним (46), 01:36, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Рейс кондишн в мейкфайле - это когда есть фактическое happens-before отношение между множеством исходников X и Y по коду, и эти X и Y собираются в разных makefile-таргетах. И при этом нет явного указания в мейкфайле, что один таргет является зависимостью другого. Господин павлин(-ункс), кто ж с тобой спорит-то, что race conditition - это борьба за общий ресурс. Здесь общий ресурс - каталог build/output, откуда все таргеты используют выхлоп друг друга. Если раньше отработает неявный дочерний таргет и положит результат в build/output, то все ок - неявный родительский таргет обнаружит что надо и успешно соберется. А если не повезет и раньше начнет работу родительский и компилятор не обнаружит чего хотел - сборка свалится.
     
     
  • 7.338, uis (ok), 13:44, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Приведи пример зависимости сборки объектника от другого объектника.
     
  • 6.402, Аноним (402), 16:54, 07/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это заблуждение часто наблюдается у программеров-прикладников, которые рейсом называют всё, что то работает, то нет. Слово-паразит.
     
  • 4.67, Онаним (?), 13:22, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что там на стабильность-то влияет?
    Собираются файлы всё равно независимо, между зависимостями сборка притормаживает.
    Финальный выхлоп делает ld, ему как-то на количество ядер фиолетово.
     
  • 3.63, Кирилл (??), 13:15, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А известно ли, какая машина у тестирующего?
    Когда я занимался правками ядра, нам выдавали простенькие атлончики. И инкремент шёл 5 минут. И можно было идти гулять.
    Торвальдс же, недавно рекомендовал amd 3970x. Как базовую машину.
    Но тут что-то мощнее.
     
  • 2.43, Аноним (40), 12:26, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И что вы с ней будете делать.Оплачивать счета за электроэнергию?
     
  • 2.128, Смузихлёб (?), 16:51, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > j96? дайте мне такую машину

    В наши дни такие машины – абсолютная норма, особенно если ты серьезный разработчик, а не веб макака. Очнитесь уже со своими core 2 duo и добро пожаловать в этот дивный новый мир.

     
     
  • 3.180, Аноним (180), 21:23, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Расшарь-ка мне пару сотен своих ядер. Раз у тебя там мир такой новый и дивный.  
     
     
  • 4.240, Иваныч (??), 13:49, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    amazon EC2 вам в помощь - не благодарите
     
  • 3.258, Аноним (258), 16:52, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Очнитесь уже со своими core 2 duo и добро пожаловать в этот дивный новый мир.

    Ты чо, как так можно? У вас там страшные штеуд МЕ, уефи и другие непонятные аббревиатуры

     
     
  • 4.261, Смузихлёб (?), 16:59, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты чо, как так можно? У вас там страшные штеуд МЕ, уефи
    > и другие непонятные аббревиатуры

    Отдельная PCI сетевуха спасёт отца русской демократии.

     
  • 2.259, Смузихлёб (?), 16:53, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > j96? дайте мне такую машину

    В наше время пользователь core 2 duo - это человек пожилого возраста или бухгалтер в не прибыльной конторе. Для большинства же пользователей двух\четырёх ядерные системы окончательно умерли в период 2015-2017 годов, оставив лишь нотки ностальгии.

     
  • 2.330, Аноним (330), 12:10, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >j96? дайте мне такую машину

    2 шт. Baikal-S

     

     ....большая нить свёрнута, показать (33)

  • 1.7, Отсутствуют данные в поле Name (?), 11:32, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Таненбаум был прав
     
     
  • 2.10, Ananima (?), 11:37, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –10 +/
    Всегда был, все это знают. Вот вам голая правда о поделии аутиста Линуса.
     
     
  • 3.83, Gogi (??), 13:44, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А чё минусуют? Всё правильно сказал. Этот Трольвадс тот ещё баран упёртый! Послушал бы "старших товарищей" - сейчас бы в ядре было 20 файлов, а всё остальное спокойно И НЕЗАВИСИМО жило в отдельных мирах.
    Короче, баранолинукс достиг стадии, когда понятно, что ишак сдохнет, но пытаются проехать лишние 100 метров.
     
     
  • 4.90, Rev (?), 13:54, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже. что в Гугле уже это поняли, причём несколько лет назад, и уже серьёзно пилять Фуксию на замену.
     
     
  • 5.95, Аноним (-), 14:16, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Фуксия они полят ради того чтобы иметь свою коммерческую Ось. Архитектура не причём.
     
     
  • 6.250, Аноним (250), 14:46, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > не причём

    схоронил

     
     
  • 7.317, Аноним (317), 07:31, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да обсохраняйся. Symbian и QNX/BBerryOS показывают, что в условиях приближенных к реальной жизни, микроядро почему-то не взлетает. Хотя концепция, конечно, красивая.
     
  • 4.145, Криптоханыга (?), 17:23, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Самое смешное - фактически к этой концепции всё и пришло! На серверах крутятся микроядерные гипервизоры, в которых на правах сервисов живую виртуалки и контейнеры. Запуск и умирание которых не приводит к падению базового гипервизора.
     
  • 4.264, keydon (ok), 17:08, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ждём ядро без фатальных недостатков от Gogi на 20 файлов.
     
  • 2.131, Смузихлёб (?), 16:54, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не зря яблоОС пошла по пути микроядерности, являясь де-факто самой надёжной осью. Хотя, конечно, играет фактор того, что и железо и ось пилит одна компания, в отличии от зоопарка ПК железа.
     
     
  • 3.247, Аноним (247), 14:37, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Там гибрид.
     
  • 3.343, uis (ok), 14:05, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Еблёс - шматки Mach 3, никакого там микроядра не осталось
     
  • 3.436, Заноним (?), 03:19, 16/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Оно и видно что смузихлёб. Всё правильно сказали - нет в огрызкоси никакой микроядерности.
     
  • 2.140, Аноним (-), 17:12, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Безусловно. Ведь он профессор, а Линус студент. Концептуально MINIX очень крутая ОС. А Linux превращается в Вавилонскую башню.
     
  • 2.165, Аноним (165), 19:24, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и где его minix теперь? Ты им сам-то хотя бы пользуешься?
     
     
  • 3.166, dflgjldfgjoldigjoildfjg (?), 19:30, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    minix everywhere - intel me :D
     
     
  • 4.344, uis (ok), 14:05, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Официально Таненбаум негодует
     
  • 3.173, Аноним (168), 21:04, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    много где - просто тебе об этом не будут сообщать.
     
     
  • 4.260, Аноним (258), 16:57, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    "У нас есть такие приборы - но только мы их не покажем" серия 100500-я. Суровое академическое BSD-строение во всей красе.
     
     
  • 5.303, Аноним (-), 19:56, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > "У нас есть такие приборы - но только мы их не покажем"
    > серия 100500-я. Суровое академическое BSD-строение во всей красе.

    С разморозкай - для SaaS, в котором сейчас заколачивают миллиарды, что GPLv2/3, что BSD - совершенно без разницы. У Гугеля вон, еще 14 лет назад был стабильный и улучшенный EXT2 и кажись, планировщик, но ...


     

  • 1.16, Аноним (16), 11:49, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Мне непонятно как они вообще всё это мержат? Он год назад делал срез, за этот год ещё куча кода, новых заголовочных файлов и т.п.

    Очень интересно как они в состоянии с этим совладать?

     
     
  • 2.21, А где же каменты (?), 11:58, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    git rebase постоянный
     
     
  • 3.26, pashev.me (?), 12:05, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ща те каргокультисты скажут, что рибэйз - это зло 🤭
     
     
  • 4.62, Какаянахренразница (ok), 13:14, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Rebase -- наше фсё. А зло это merge.
     
     
  • 5.76, user (??), 13:36, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Костыль для любителей линейной истории.
     
     
  • 6.107, А где же каменты (?), 15:13, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Merge комиты выглядят уродливо. Какие у merge стратегии преимущества перед rebase?
     
     
  • 7.120, Какаянахренразница (ok), 16:21, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Моё дело -- вбросить. А дальше вы уж как-нибудь сами.
     
  • 7.169, Аноним (53), 21:02, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Давно ли они стали альтернативой друг другу?
     
     
  • 8.181, А где же каменты (?), 21:28, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да, всегда были... текст свёрнут, показать
     
  • 7.196, мое правило (?), 23:34, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    С мердж комитами прикольно. Иногда надо покупать парочку пузырей водяры, звать пацанов что бы разобраться как и куда идут эти сраные ветки. С линейной историей поводов с пацанами собратся будет меньше :(
     
  • 7.314, fuggy (ok), 02:47, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ребейз это переписывание истории, то есть вместо одно коммита создаёт на его основе новый коммит, который не тоже самое. Если автор взглянет на свой коммит после ребейза, он его не узнает. Коммит будет отличатся от того чтобы было задумано, но будет сформирован автоматически, от чего может возникнуть ошибка там где её никто не ждал. А уж о проблеме что это полностью портит работу остальных, кто ответвился до ребейза и говорить не стоит.
     
     
  • 8.352, Аноним (46), 14:31, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    1 Если конфликты при ребейзе, то они будут и при мердже и всё равно придется ак... текст свёрнут, показать
     

  • 1.25, pashev.me (?), 12:04, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В Солярке такая же беда.
     
     
  • 2.234, Аноним (234), 13:10, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В случае солярки это проблема вида "цветки на могилке слишком быстро вянут".
     

  • 1.29, Аноним (40), 12:10, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Не факт что расспаралеливание кода на ядрах процессора приносит улучшенную  стабильность бинарника на выходе.Сами разработчики GCC рекомендуют иногда компилировать в один или два потока.Так что новость актуальна.Можно компилить теперь в один поток быстрее.У кого эпики или 100500 ядер профита не получат вообще.
     
     
  • 2.51, Аноним (53), 12:48, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Какая ещё стабильность бинарника, деточка? Иди уроки делай. И запомни, что распараллеливание сборок на конечный ре0зультат не влияет. Но не всегда оправданно, потому что рано или поздно бутылочным горлышком окажется io.
     
     
  • 3.54, Аноним (40), 12:57, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Деточка это вы почитайте доки gcc и gentoo потом пишите.А еще поинтересуйтесь как разрабатывается код под процессоры для орбитальных спутников и космических зондов.Да ракеты забыл извините деточка.  
     
     
  • 4.174, Аноним (53), 21:05, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И сейсас ты такой — хопа! — вывалил ссылки на нужные места доки gcc и gentoo и рассказал тру стори, как разрабатывал код для спутников, какие нашёл грабли, и в чём была их причина.
    Эх, что-то размечтался я…
     
     
  • 5.212, Аноним (40), 09:39, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это секретная информация.Государственная тайна.Вам деточка этого никто не раскажет.Так что товарищ майор иди ищи дураков и делай себе карьеру в другом месте а здесь на форуме приличные люди программисты.
     
     
  • 6.223, Прохожий (??), 11:06, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >нужные места доки gcc и gentoo

    Это гостайна? :)))

     
     
  • 7.345, uis (ok), 14:09, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В нужных местах можно узнать всё, а всё - гостайна, значит и нужные места тоже
     
  • 2.77, Аноним (46), 13:37, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Уважаемый, какая "параллельная" компиляция на GCC? Каждый отдельный unit of compilation собирается в 1 поток (потому что при добавлении параллелизма теряется sequential context и из-за этого теряется возможность многих важных оптимизаций). Там только в 2020 году на Google Summer of Code был хакатоновский проект по добавлению параллелизации в сборку отдельного юнита, который до сих пор в стадии proof-of-concept. Сейчас параллелизация происходит только на уровне Make-файлов, когда независимые рецепты собираются одновременно.
    Все баги, которые лезут при параллельной сборке, происходят из-за криво написанных Make-файлов или из-за состояний гонки внутри самой утилиты make.
     
  • 2.91, Кирилл (??), 13:55, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если нестабильность на уровне сборки - надо заводить багу.
    Искать повторяемость ошибки.
    Потом локализовывать место возникновения.
    И затем исправлять.
    Исправлять какие ошибки не сложно. Так как можно закрыть ошибку меньше, чем за неделю.

    Главное не плодить правила сборки.
    И не искать виновных.
    Толка чуть. Не Боги горшки лепят. Все ошибаются.
    И исправить можно.

     
     
  • 3.106, Аноним (96), 15:13, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какой умный мальчик. Ящик печенья и банку варенья герою.
    Проблема глубже, чем воспитала юных хакеров современная система: компилируется - значит работает.
    Всегда есть сложновоспроизводимые проблемы из-за гонок, отсутствия необходимого железа, реверс-инжиниринга для поддержки проприетарного железа или наличие крикливых индусов с LGBT+ поддержкой. Из-за этого поддержка кода превращается в кривой спаггеттинг, вносятся изменения в зависимости от каждой платформы или вносятся противоречивые правки через дефайны, которые очередным индусом-оптимизатором приводятся к неработающему коду.
     
     
  • 4.189, Аноним (189), 23:10, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ты пьян, обдолбан или просто шизофреник?
     
     
  • 5.371, нах.. (?), 17:07, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, он просто говорит правду. А такие как ты ее никогда не слышали или не желают слушать. Вас воспитала та самая система.
     
  • 2.148, макпыф (ok), 17:46, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что ты несешь? 1. Причем тут вообще расспаралеливание 2. На уровне make это ни как не влияет на сами бинарники
     
  • 2.265, Michael Shigorin с дороги (?), 17:14, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > улучшенную  стабильность бинарника

    Что Вы несёте?

     
     
  • 3.434, примерно_36_скотинок (ok), 15:59, 13/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ну он медленнее распадается и гниёт. период полураспада опять же увеличивается.
     

  • 1.30, Аноним (30), 12:10, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Быдлокод на сях - это быдлокод в квадрате. Побочный эффект от того, что заголовочные файлы просто тупо инклудятся друг в друга, так что небольшой с виду код может в итоге оказаться для компилятора просто гигантским. Ну и перекомпиляция одного и того же по 100500 раз. Проблема решена в делфях, где юниты компилятся отдельно. Это делает компиляцию почти мгновенной. Но есть проблема. Перекресные ссылки невозможны. И это немного противоречит логике. Т.к. то, что можно реализовать внутри одного модуля, почему то нельзя реализовать, если просто для красоты разделить программу на два. Приходится танцевать с бубном. Но такая вот специфика. За скорость нужно платить.
     
     
  • 2.36, Аноним (40), 12:16, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так ведь Delfi вроде мертв.Не?
     
     
  • 3.101, Аноним (30), 14:42, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Он мертв не поэтому. А потому, что кто то хочет овердофига бабла за лицензию. А лазарус, как и любая другая слоупочная опенсурцная муть, развивается крайне медленно. По релизу (условно) в год с мелкими исправлениями. Иногда мне кажется, что эти опенсурцеры просто в игрульки играются. Мол у нас есть проектик. Мы с ним играемся. Но у нас по сути нет ни одного человека, который мог бы реализовать что то реально стоящее. А потому мы раз в год прикрутим какой нибудь маленький фикс совместимости с делфи.
     
     
  • 4.157, ms is piece of s (?), 18:20, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Но у нас по сути нет ни одного человека, который мог бы реализовать что то реально стоящее.

    Кто тебе мешает стать этим самым человеком?

     
     
  • 5.266, Michael Shigorin с дороги (?), 17:14, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Обычно это лапки...
     
  • 4.184, Аноним (182), 21:47, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Double Commander. Вполне солидный проект.
     
  • 2.273, другой Вася2 (?), 17:32, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Но есть проблема. Перекресные ссылки невозможны

    Очень даже возможны. Попробуйте часть ссылок в "interface", а остальные в "implementation"

     

  • 1.33, pashev.me (?), 12:13, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Идеальное прикрытие для внесения бэкдоров.
     
     
  • 2.213, Аноним (-), 09:39, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это русский?
     
     
  • 3.267, Michael Shigorin с дороги (?), 17:15, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Инго-то Мельниченко?
    Не, куда там.
    Но мужик грамотный.
     

  • 1.38, Аноним (38), 12:18, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Если примут, то это на 6.0 уже потянет
     
     
  • 2.41, Аноним (40), 12:24, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Примут примут обязательно ждемс с нетерпением.
     

  • 1.45, kot to (?), 12:31, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Про Rust Уже вспомнили ?
     
     
  • 2.70, Аноним (65), 13:26, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    вспомнили что не нужен
     
     
  • 3.215, Прохожий (??), 10:11, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Разве что таким неосиляторам, вроде тебя.
     
     
  • 4.251, Аноним (250), 14:48, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    я начинал учить раст, очень его хвалили, но умер от потери крови, вся из глаз вытекла от синтаксиса. пишу с того света
     
     
  • 5.342, DyadyushkaAU (ok), 14:01, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > я начинал учить раст, очень его хвалили, но умер от потери крови,
    > вся из глаз вытекла от синтаксиса. пишу с того света

    Может к окулисту сходишь для начала? Обычно, люди склонны винить всех вокруг в своих бедах, только не себя.

     
  • 2.78, Анонн (?), 13:37, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зачем о нем вспоминать если это было сделано по-человечески еще в делфях задолго до раста?
    Хотя у него с модульностью тоже все прекрасно. Вообще сложно представить хоть что-то, где модульность будет хуже чем в си.
     
     
  • 3.233, DyadyushkaAU (ok), 13:09, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем о нем вспоминать если это было сделано по-человечески еще в делфях задолго до раста?

    Delphi не бесплатны. Rust - бесплатен. Хотя бы поэтому. У Rust удобней инфраструктура (ИМХО). Rust поддерживают MS, Google, Mozilla, Huawei. Delphi - только Borland, которая уже далеко не торт.

     
     
  • 4.288, Аноним (286), 18:07, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >У Rust удобней инфраструктура (ИМХО).

    Тоже программироуешь браузеры?

     
     
  • 5.339, DyadyushkaAU (ok), 13:51, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Rust не только для браузеров подходит.
     
  • 2.346, uis (ok), 14:12, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Что? Зачем?
     

  • 1.47, Аноним (321), 12:36, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Проблема в том, что с точки зрения функциональности, стабильности, надёжности, безопасности и скорости работы эти патчи ничего не улучшают. Для пользователей эти патчи ничего не добавляют, но при таком объёме изменений возникновение функциональных регрессий почти неизбежно, а эти регрессии уже могут влиять на качество работы ядра, а не только на удобство его сборки.
     
     
  • 2.49, Аноним (40), 12:41, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Совершенно верно вот и надо будет больше тестов а потом как всегда патчи патчи и еще раз патчи.Энтропия вселенной однако.
     
     
  • 3.60, tty0 (?), 12:59, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как практик, могу сказать, что после повышения времени сборки 3 минут - ошибки начинают возникать просто из-за вынужденной смены контекста при ручной проверке
     
  • 2.61, Аноним (61), 13:08, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Патчи приводят кодовую базу в порядок. Из-за свободы, которую даёт разделяемая сборка в С и С++, разработчикам часто сносит голову, и они начинают включать заголовки не глядя, создавая бардак из перекрестных включений. Что не только существенно замедляет скорость сборки, но ещё затрудняет понимание структуры кода человеком, а также приводит к незаметным ошибкам связанным с порядком обработки препропроцессором объявлений-макросов.
    В С++ уже приняли modules, которые в перспективе могут улучшить ситуацию. А вот в С остаётся уповать только на разработчиков. Но люди - это всегда слабое звено: они невнимательны, глупы и ленивы.
     
     
  • 3.82, Аноним (250), 13:43, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > разработчикам часто сносит голову, и они начинают включать заголовки не глядя, создавая бардак из перекрестных включений.

    но ты, конечно, не из их числа, зато аналитика у тебя уровня 80

     
  • 3.152, Аноним (16), 18:03, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Так ты плати за рефакторинг и проблем не будет. Аааа...не хочешь? Ну тогда терпи.
     
  • 3.156, Аноним (-), 18:16, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    в линуксе заголовочные файлы адский ад, тут включи дефайны gnu, там bsd и смотри не перепутай, соберётся, но с ошибками в процессе работы.
     
  • 3.224, Прохожий (??), 11:11, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Линукс написан на Си. Там НЕ БУДЕТ Си++. Поэтому появившаяся в этом языке модульность ничего не изменит. Шанс есть только у  Rust пока что.
     
  • 2.85, Аноним (46), 13:48, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Как бэкенд разработчик в ентерпрайз проекте на 3 млн строк кода, выражу мнение, что без чисто технического рефакторинга, который ничего продуктового не добавляет, а только уменьшает техдолг тяп-ляпных архитектурных решений, проект со временем становится невозможно сопровождать. В каждой большой компании есть правило, что N процентов спринта команды отводится на ликвидацию имеющегося техдолга.
     
  • 2.268, Michael Shigorin с дороги (?), 17:22, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если маме освободить больше времени скажем, купив стиралку или посудомойку -- ... большой текст свёрнут, показать
     
     
  • 3.301, jezhik (?), 19:51, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Однако в реальности после обретения стиралки эта мама будет либо больше залипать в сериалы, либо сможет лишние пару раз вымыть полы или протереть пыль.
    Так люди устроены.
     
  • 2.347, uis (ok), 14:13, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Эти регрессии будут способствовать на порядки большей прогрессии
     

  • 1.64, Аноним (64), 13:16, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    "с 15.5 до 27.7 сборок в час" ниочом же, мой монитор 144fps. Я хочу 1 сборку на каждый фрейм. Играть в линукс на ~30fps это слайдшоу. Жду новые райзены TR с DDR5.
     
     
  • 2.87, Анон_ли (?), 13:52, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Путаешь частоту обновлений с частотой кадров.
     
     
  • 3.269, Michael Shigorin с дороги (?), 17:23, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Он часы с секундами путает (и fps с bph), если что... но типа смешно.
     
  • 2.125, Аноним (122), 16:44, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Забуферизируй каждую сборку и выплюни её в 144 кадра, когда всё случится. А чё, сейчас пинг с карты в 20 мс — это норма, народу нравится.
     
  • 2.150, mikhailnov (ok), 17:58, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А вы запустите сборку ядра с высокой говорливостью, будет не успевать выводить в терминал, при должной оптимизации, возможно, упретесь в 144 FPS, были же новости про GPU-ускорение для отрисовки текста в терминалах, над ними смеялись, а вот оно и пригодится.
     

  • 1.71, th3m3 (ok), 13:28, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чую нас ждёт год оптимизаций. Будет круто, если эти патчи примут в этом году. К концу года Python ускорят. Явно будет ещё что-то.
     
     
  • 2.80, Аноним (65), 13:38, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вот бы ещё пайтоновцы немного на другие, особенно мобильные, архитектуры хоть иногда смотрели и собирали либы и под них, цены бы им не было
     
  • 2.175, Аноним (53), 21:11, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > К концу года Python ускорят.

    Скажи ещё, GIL выпилят.

     
     
  • 3.188, Аноним (17), 23:09, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не выпилят, но сделают возможность в одном процессе спаунить subinterpreters. Это можно и сейчас уже в 3.10, но сейчас подинтерпретаторы шарят GIL. А в 3.11 обещают сделать, чтобы каждый subinterpreter имел свой собственный GIL. Если это сделают - то ты сможешь делать в одном процессе сколько угодно независимых объектов-интерпретаторов, не шарящих общий GIL, глобальный для процесса. А значит ты сможешь в мультитрединг с закэнселленым GIL.
     
     
  • 4.197, JavaScript (??), 23:49, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Питоновцы изобретают Веб-Воркеры.
     
     
  • 5.397, Аноним (397), 20:52, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Питоновцы могут запускать ивент лупы программно, прикинь! Надеюсь с пальмы не упал?
     

  • 1.79, Gogi (??), 13:38, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    ...и вся эта помойка развивалась под неусыпным наблюдением главного Пингвинукса-трольвадса... он что, вообще ни в зуб ногой в Си? Неужели городить помойку годами не вызывало у него хотя бы инженерного чувства брезгливости? Тоже мне, "революционер"!
     
     
  • 2.97, Аноним (-), 14:21, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Гоги вы чьих будете? За Паскаль топите.
     
  • 2.126, Аноним (122), 16:48, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы бы патчи ему кидали, а не гнали на человека лишний раз. Он написал ядро и дожил до 2022, всё ещё находясь в статусе его мейнтейнера. Пора ли деду на пенсию или нет — вопрос субъективный, но факт в том, что содержать такую большую помойку из кода, который работает и работает великолепно в 99% случаев — это как минимум достойно уважения.
     

  • 1.81, Rev (?), 13:42, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > на стадии постпрепроцессинга

    Что за дебильный язык, в котором нужна фаза пост-пре-процессинга???

     
     
  • 2.92, Gogi (??), 13:55, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    гbI-гbI :) Добро пожаловать в 70-ые! Время _килобайтной_ памяти и самых маразматических решений в ИТ!
    Каждый язык развивался в меру шизанутости авторов (привет, ЛИСП!) и потому ТОГДА это никого не удивляло и не вызывало инженерных споров. Сегодня Си - самое маразматичное, что можно использовать для разработки.
     
     
  • 3.103, Аноним (103), 14:52, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Сегодня это любой язык, Сишечка просто не прячет этапы и позволяет исполнять их раздельно. Маразматично выбирать язык по принципу лишь бы хайповым был, на сегодня у си нет альтернатив по качеству и эффективности батареек и нет никаких предпосылок к изменению ситуации. Я даже не вижу что через 30 лет какой-нибудь язык мог бы сравняться с сишечкой, может быть плюсы лет через 100 догонят.
     
     
  • 4.109, Анонн (?), 15:23, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Сегодня у си нет альтернатив по количеству рукожопства с памятью, выходов за границы массива и переполнений буфера (и тысяч cve как результат). С ним может поспорить только с++ в проектах, для погромистов которых это всего лишь "си с классами" и они не используют правильное RAII ради мнимой производительности, а таких еще очень много.
     
     
  • 5.111, Аноним (103), 15:37, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хотя бы быстро компилируется и работает. Современные инструменты позволяют избегать большинства ошибок. Статистически все эти переполнения случаются в 1 из миллионов случаев применения адресной арифметики, что не так и плохо. Критические ошибки с перепутанными знаком, порядком аргументов, или прочее подобное случаются куда чаще и в любом языке, и от них нет никакой защиты.
     
     
  • 6.155, Анонн (?), 18:13, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    От перепутанного знака могут помочь юнит-тесты, от неправильной бизнес-логики - интеграционные.
    А от выхода за границы массива при неудачных входных параметрах - даже фаззи-тестинг помогает в единичных случаях. Так что мимо.
     
     
  • 7.162, Аноним (103), 18:47, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему тогда не помогают?
     
     
  • 8.263, Аноним (258), 17:06, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Потому, что теоретизировать - это вам не код писать ... текст свёрнут, показать
     
  • 5.121, YetAnotherOnanym (ok), 16:22, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > нет альтернатив по количеству рукожопства с памятью, выходов за границы массива и переполнений буфера

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

     
     
  • 6.143, Анонн (?), 17:21, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не, ну зачем вы так про разрабов ядра linux, openssl, xorg, firefox и сотен других.
    Они вполне неплохие люди и программеры, не нужно их так обижать. Но раз в год они себе стреляют в ногу, а иногда оно ее отрывает по самую Ж, причем не только им, но и миллионам благодарных юзеров.
     
     
  • 7.163, Аноним (103), 18:52, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дело тут скорее в сложности продуктов. Да и на "безопасных" языках что-то не спешат пилить альтернативы (они ещё и конкурентоспособными должны быть при этом). Всех достижений "мы переписали очередной приветмир на додиез".
     
     
  • 8.218, Прохожий (??), 10:28, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пилят потихоньку Просто достаточной массы разработчиков не набралось пока ... текст свёрнут, показать
     
     
  • 9.319, Аноним (234), 07:47, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И не наберётся То ж не формы на венде клепать, тут думать надо ... текст свёрнут, показать
     
     
  • 10.349, DyadyushkaAU (ok), 14:17, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по опросам StackOverflow - процесс пошёл А ты и дальше можешь продолжать ... текст свёрнут, показать
     
  • 8.381, Аноним (381), 02:19, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тут все не так просто и с Си, и с безопасными языками Ведь процессор ну абс... большой текст свёрнут, показать
     
     
  • 9.388, YetAnotherOnanym (ok), 16:41, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дай я пожму твою руку ... текст свёрнут, показать
     
  • 6.271, Michael Shigorin с дороги (?), 17:26, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > У тех, кто прогуливал в школе арифметику и не умеет складывать-вычитать целые числа.

    Как хорошо, что в России таких негров можно называть неграми.

     
     
  • 7.359, DyadyushkaAU (ok), 15:07, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У вас логическая ошибка в высказывании (безотносительно к расистской сути такового): не все негры безграмотны, и не все безграмотные - негры. Причём здесь Россия, кстати? В ней негры живут, что ли?
     
  • 4.187, Олег (??), 22:55, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Согласимся. По факту это так. Заменить Си нечем :-(. Какой бы он ни был, остальное прочащее на егг замену ещё хуже.
     
     
  • 5.217, Прохожий (??), 10:25, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Rust. Вполне адекватная замена.
     
     
  • 6.318, Аноним (234), 07:46, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В "замене" двусвязный список без unsafe уже осилили, или как обычно "не работает - не нужно"? Платформы, отличные от попсового x86 осилили, или как обычно? Сборку стандартной библиотеки без gc осилили или как обычно?
     
     
  • 7.333, Аноним (-), 12:57, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сборку стандартной библиотеки без gc осилили или как обычно?

    Опеннетовске Воены Антирастового Сопротивления непутание методичек осилили или как обычно?


     
     
  • 8.382, Аноним (234), 06:36, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Когда крыть нечем, но что-то выcpать надо ... текст свёрнут, показать
     
     
  • 9.386, Аноним (-), 13:28, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А ты самокритичный Осознание - первый шаг к чему-то там, так держать ... текст свёрнут, показать
     
  • 4.350, uis (ok), 14:23, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Добавят векторизацию на уровне языка, и ещё 100 лет будет не догнать
     
  • 3.270, Michael Shigorin с дороги (?), 17:25, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Каждый язык развивался в меру шизанутости авторов (привет, ЛИСП!)

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

    hint: sexp

     
  • 2.110, Анонн (?), 15:36, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Си это просто пхп своего времени. Даже хуже, у пхп вначале была эталонная реализация, а относительно нормальные альтернативы начали появляться с версии 5+.

    У си куча диалектов была с момента создания, куча несовместимых компиляторов, расширений.
    Никто не думал об архитектуре, главное быстрее портировать юникс на очередной комп. Х*як-х*як и в прод. Первый стандарт появился только лет через 15 после создания языка, и то - они просто записали что уже было по факту.

    Плюс наяривание на обратную совместимость, из-за которого невозможно выкинуть всю каку, которая накопилась за эти 50 лет.

    Поэтому и существует такая шизофазия как "постпрепроцессинг"

     
     
  • 3.351, uis (ok), 14:30, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У си куча диалектов была с момента создания, куча несовместимых компиляторов, расширений.
    > Никто не думал об архитектуре, главное быстрее портировать юникс на очередной комп.

    MSVC видимо тоже юникс собирает. А остальные компиляторы, как ни странно, все поддерживают расширения из gcc.

    > Плюс наяривание на обратную совместимость, из-за которого невозможно выкинуть всю каку,
    > которая накопилась за эти 50 лет.

    Обратную совместимость винды, на которой ты сидишь, обратную совместимость x86 со своим предком из 70-х.

     

     ....большая нить свёрнута, показать (27)

  • 1.88, Gogi (??), 13:53, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Что приятно, в Линуксе таки находятся адекватные люди! Сначала переделали файловый бардак и сделали Gobo-linux. Потом (когда до остальных слоупоков дойдёт) это станет мэйнстримом. Затем заголовочники поправят, пофиксив БАРДАК, который Линус разводил десятилетиями. Ну а потом уж дозреют и до перехода на Ди! Но это будет уже при наших внуках.
     
     
  • 2.98, Аноним (-), 14:24, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >переделали файловый бардак и сделали Gobo-linux

    Как в Виндовсе?

    >Ну а потом уж дозреют и до перехода на Ди! Но это будет уже при наших внуках.

    Гоги топит за язык Ди.

     
     
  • 3.129, Аноним (122), 16:52, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Предлагаю Гоги сделать главным мейнтейнером языка Ди (хотя почему Гоги не предложит написать линукс на Porth или другом, например своём самопальном языке — не понятно). Предлагаю проект назвать соответствующе: "Дикс". А что, звучит!
     
  • 2.104, Аноним (103), 14:57, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    За 15 лет не написано ничего известного, у раста куда больше шансов получить распространённость (not to mention раст, в отличие от д, не завязан на рантайм с гц).

    ПС. гоболинукс -- помойка.

     
     
  • 3.206, Аноним (205), 06:00, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Шансы равны и равны 0
    Обе поделки поделаны чтоб быть и не несут никаких новых концепций
    Маркентинговое оно
     
     
  • 4.207, Аноним (103), 07:24, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сахарок приятный в принципе.
     
  • 4.219, Прохожий (??), 10:37, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Обе поделки поделаны чтоб быть

    Не чтобы быть, а чтобы избавиться от тех годами копимых "наработок" на Си, Си ++.

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

     
     
  • 5.222, Аноним (103), 11:02, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >на нормальном языке с нормальной инфраструктурой

    На го нельзя писать системный софт. Можно, если очень хочется, но нельзя. О многих вещах можно сразу забыть.

     
     
  • 6.235, DyadyushkaAU (ok), 13:18, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, предыдущий высказывающийся имел ввиду Rust, а не Go.
     
     
  • 7.239, Аноним (103), 13:44, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Но ведь то, что он сказал, явно не про руст с его нпм. И в его нпм нет ничего примечательного. А в самом языке нет ничего инновационного или уникального, всё выглядит как костыли для жс-обезьян. Нет готовых батареек, наконец, а те, что есть, работают ощутимо хуже плюсов.
     
     
  • 8.274, Michael Shigorin с дороги (?), 17:33, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чего ... текст свёрнут, показать
     
     
  • 9.353, uis (ok), 14:35, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ржавая версия NPM Как pip в питоне ... текст свёрнут, показать
     
     
  • 10.356, DyadyushkaAU (ok), 14:49, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    cargo в Rust куда как функциональней, чем pip в Python ... текст свёрнут, показать
     
  • 8.355, DyadyushkaAU (ok), 14:47, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У Rust нет NPM Ты его с чем-то другим попутал В самом языке есть - строгая ти... большой текст свёрнут, показать
     
     
  • 9.363, Аноним (103), 15:47, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В первом предложении ты утверждаешь, что нет нпм, потом льёшь список воды, и зав... текст свёрнут, показать
     
     
  • 10.365, DyadyushkaAU (ok), 15:59, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    У Rust нет NPM Или ты централизованную систему пакетов имел ввиду Если да, то ... текст свёрнут, показать
     
     
  • 11.367, Аноним (103), 16:24, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не систему пакетов, а доверие вендору и к тому, что в гнилой помойке нет и не бу... текст свёрнут, показать
     
     
  • 12.368, DyadyushkaAU (ok), 16:35, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ясно, чукча не читатель И снова проблемы с логикой Если ты находишь код б... текст свёрнут, показать
     
     
  • 13.370, Аноним (103), 17:03, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В серьёзном бизнесе не доверяют никаким хранилищам если только поставщик мамой ... текст свёрнут, показать
     
     
  • 14.385, DyadyushkaAU (ok), 13:21, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не доверяем - не пользуемся Или кто-то заставляет Вроде, простое решение, а по... текст свёрнут, показать
     
     
  • 15.424, uis (ok), 17:02, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я вижу очередной npm, оно тоже не просто загружатель, но и система сборки и то... текст свёрнут, показать
     
     
  • 16.429, DyadyushkaAU (ok), 23:04, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Куда-то не туда ты смотришь npm - это менеджер пакетов - не совсем то же самое,... текст свёрнут, показать
     
  • 9.423, uis (ok), 16:53, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Читаю Си, Ада ... текст свёрнут, показать
     
     
  • 10.430, DyadyushkaAU (ok), 23:15, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не тем местом читаешь И к ARM, и к MIPS, и к RISC-V, и к SPARC Подробности h... текст свёрнут, показать
     
  • 2.203, Аноним (203), 02:01, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Gobo linux даже не смогли pendrive install запилить,
     
  • 2.272, Michael Shigorin с дороги (?), 17:31, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сначала переделали файловый бардак и сделали Gobo-linux. [...]
    > Но это будет уже при наших внуках.

    Какие ваши внуки, трансгендерно-восхищённые "постчеловеки"?!

    // нет, это прям какие-то кульбиты высшего пилотажа в самовляпывании в антиориентиры

    PS: технарям, а также сомневающимся, напомню статью Витуса Вагнера примерно двадцатилетней давности, которая за прошедшее время стала только актуальней, как по мне (и теперь выглядит сказочно "неполиткорректной" на фоне того, во что ударными темпами скотился и продолжает скатываться коллективный запад): http://wagner.pp.ru/~vitus/articles/user-friendly.html

     
     
  • 3.305, Аноним (124), 20:51, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Статья примерно из той же оперы что и разговоры малочисленных и нищих совковых автовладельцев о превосходстве "механики" над "автоматом".
     
     
  • 4.328, Аноним (328), 12:00, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ремонтопригодность? Не, для поколения айфонов и тиктоков это слишком сложная концепция. Лучше заменим всё целиком, а то пепельница переполнилась.
     
     
  • 5.329, Аноним (124), 12:06, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так ведь и автоматы вполне себе ремонтируют, не?
     
  • 3.358, DyadyushkaAU (ok), 15:05, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как приведенная статья противоречит (опровергает) то, что сделано создателями GoboLinux?

    Автор статьи, кстати, абсолютно прав: программа должна быть рабом у человека. Сказали - сделала.

    GoboLinux организацию файловых систем приближает как раз к такому идеалу - человеку нет нужды задумываться (как в других дистрах) о том, где он может найти те или иные бинарники (и/или другие файлы): они всегда будут находиться в одной и той же стандартной структуре папок. Что же в этом плохого, кроме того, что многие админы (и другие пользователи) уже успели привыкнуть (то есть, по сути прогнуться под создателей дистров) к прежней непрозрачной структуре?

     

     ....большая нить свёрнута, показать (29)

  • 1.100, Аноним (100), 14:39, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Следующим шагом будет обфускация заголовочных файлов для экономии места и очередного ускорения
     
     
  • 2.130, Аноним (122), 16:54, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так це наоборот, деобфускация. Вместо заголовков-всё-в-одном, a.k.a. просто-добавь-заголовок, будут самодостаточные заголовочные файлы без дичайших вложений.
     

  • 1.105, Аноним (105), 14:59, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Вот щас придёт линус в lkml и покажет всем свой финский палец!
     
     
  • 2.202, john_erohin (?), 01:48, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    шведский.
     
     
  • 3.210, Брат Анон (ok), 09:20, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Всё-таки финский. Его отец был финном.
     
     
  • 4.225, Аноним (225), 11:41, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а мама таки да?
     
  • 4.421, Аноним (421), 11:21, 10/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Шведом. Хоть и гражданином независимой Финляндии.
     

  • 1.112, Аноним (168), 15:48, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    а есть такие же патчи, только что бы сам комп на столько же быстрее работал?
     
     
  • 2.275, Michael Shigorin с дороги (?), 17:40, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сам комп не умеет, а так вот небольшой комментарий к нашумевшему недавно тести... большой текст свёрнут, показать
     
     
  • 3.292, Аноним (124), 18:53, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Почему-то любое упоминание Эльбрусов наводит меня на воспоминания об одной статье в журнале "За рулём", советских ещё лет, то ли про ГАЗ-14, то ли про ЗИЛ-117, уже не помню... В той статье авторы всячески расписывали этот автомобиль, отмечая продуманную конструкцию, удобство салона и прочие бесспорно имевшие место достоинства данного аппарата. Вот только финал статьи был беспощадно обескураживающим: этот автомобиль создавался в качестве конкурента таким автомобилям как Роллс-Ройс и Кадиллак, предназназначается он для партийного руководства, а главной целью его создания является выполнение представительских функций для поднятия престижа страны; обычные граждане этот автомобиль купить не смогут.
     
     
  • 4.297, iZEN (ok), 19:38, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Эльбрус никому не нужен. Это — тупиковая ветвь развития микропроцессоров, поддержанная только деньгами. Желания использовать это убожество никогда ни у кого не возникало.


     
     
  • 5.300, Аноним (258), 19:47, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Отучаемся говорить за всех (с). Я бы купил себе (незадорого), так не продают же.
     
     
  • 6.311, Аноним (124), 23:47, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не переживай, после того как чуть ли не половина тамошних пламенных борцов за "русский процессор" перешли в Yadro, стоило только помахать у них перед носом хрустящей бумажкой, скоро и продавать будет нечего.
     
  • 6.332, john_erohin (?), 12:37, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я бы купил себе (незадорого), так не продают же.

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

     
  • 3.298, Аноним (258), 19:45, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >PS: а так-то самому интересно, куда и чьей рукою из технических выводов пропал пункт 3 -- про ограниченную, но уже применимость серийных эльбрусов к поставленным в том тестировании задачам.

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

     
  • 3.354, uis (ok), 14:39, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если бы не закрытость эльбрусов...
     
     
  • 4.360, Аноним (124), 15:24, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Увы, это характерная черта русского человека - много философствовать о человеческой природе, о добре и зле и прочих высоких материях, но в реальной жизни палец о палец не ударить, чтобы сделать для людей что-то хорошее. МЦСТ даже утопая не протянет руки сообществу. Обратите внимание насколько это контрастирует с США, которые при всех своих недостатках подарили миру множество интересных проектов, многие из которых также были закрытыми, а то и вовсе засекреченными...
     
  • 4.362, pofigist (?), 15:41, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы не убогость архитектуры... DSP-переросток.
     
     
  • 5.417, . (?), 10:32, 09/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Они считают это - достижением. Опыт itanium ничему не научил. При том что в нем гораздо меньше было свалено на компилятор (но даже и этого интел нешмог на все интеловские и хулетовы деньги)

     
     
  • 6.420, pofigist (?), 22:56, 09/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Они считают это - достижением. Опыт itanium ничему не научил. При том
    > что в нем гораздо меньше было свалено на компилятор (но даже
    > и этого интел нешмог на все интеловские и хулетовы деньги)

    И ладно бы только итаниум... Эта архитектура была модной лет 25 назад, но в результате - ее все закопали, не только интел.

    Я если смутно понимаю как этот монстрик будет оптимизироваться под выполнение в СВМ... Куда пойдет вся его оптимизация в момент переключения контента исполнения?

     
  • 3.418, . (?), 10:38, 09/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > мол, так надо же взять вот эту версию и там к ней ключики указаны.

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

    А у МЦСТ НЕТ никакой другой более быстрой версии и волшебных ключиков, краденый код gcc как-то к тому не располагает. Только "приведенный к частоте" FUD и остается.

     
     
  • 4.419, n00by (ok), 12:17, 09/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я не понял смысл наброса, разве GCC украли EDG фронтенд?
     

  • 1.115, Аноним (115), 15:53, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Будем теперь ядро на 486 собирать за ночь
     
  • 1.116, Не будь васяном (?), 15:56, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Это ж какая сейчас скорость сборки тормозная если её можно "оптимизировать" на 50-80% 🤣 Мир Линукса как он есть. Без розавых очков.
     
     
  • 2.134, Аноним (122), 16:59, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На стриме у одного человека видел, насколько тормозной на самом деле nasm (это ассемблер, если чё, т.е. даже не в Си дело) и какие жирные бинарники он выдаёт по сравнению с fasm (у которого нету документации, но всё таки). Скорость достаточно небольшого проекта с 7 секунд (включая компилятор его собственного языка) и мегабайта статического бинарника упала до 2 секунд и килобайта статического бинарника. Может стоит ещё и инструментарий чекнуть, не только код линукса.
     
     
  • 3.144, Аноним (-), 17:21, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > и какие жирные бинарники он выдаёт по сравнению с fasm (у которого нету документации, но всё таки).

    *рукалицо*
    Жир бинарника в асме - иключительно вопрос прямизны рук (или желания заморочиться) асмщика.
    Что касается документации FASM - все с ней нормально
    https://flatassembler.net/docs.php
    (причем еще 12 лет назад было - я как раз переписал проектик на пару тыщ строк с MASM на FASM)
    Но да, оно в виде текста, а не видосика на ютубе.

     
  • 3.146, макпыф (ok), 17:37, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > nasm

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

     

  • 1.118, Линус (?), 16:05, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Что приятно, в Линуксе таки находятся адекватные люди!

    та не! этот чел просто захотел славы.

     
  • 1.127, YetAnotherOnanym (ok), 16:51, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот это новогодний подарок! Кто-то начал разгребать эти авгиевы конюшни! Респектище!
     
     
  • 2.138, Смузихлёб (?), 17:06, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    По хорошему нужно раз в несколько лет переписывать всё с нуля с оглядкой на актуальное железо, а не тянуть гору костылей, прослоек и надстроек.
     
     
  • 3.147, Аноним (147), 17:40, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ниче что у Линукса чаще чем всегда проблемы с новыми железками?)
     
     
  • 4.151, Аноним (103), 17:58, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При чём тут линукс? Это обязанность производителя поддерживать железо. Всегда поддержку пилят разрабы на зарплате. Просто с линуксом у анонима есть опция поправить что-то самому, а с вендой через пару лет после покупки всё железо отправляется на помойку. Если оно вообще будет работать, например, усб звуковухи с амдшными камнями не работали, когда я в прошлый раз проверял.
     
     
  • 5.220, Прохожий (??), 10:46, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Много ты знаешь пользователей, которые сами драйвера поправляют?
     
     
  • 6.257, Смузихлёб (?), 16:50, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Много ты знаешь пользователей, которые сами драйвера поправляют?

    Та даже системный программист не сможет это сделать не имея на руках спецификации от производителя железа.

     
     
  • 7.284, Аноним (103), 18:02, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Много ты знаешь пользователей, которые сами драйвера поправляют?
    > Та даже системный программист не сможет это сделать не имея на руках
    > спецификации от производителя железа.

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

     
  • 6.310, YetAnotherOnanym (ok), 22:40, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Много ты знаешь пользователей, которые сами драйвера поправляют?

    Эээ... ну, я однажды vid&pid в .h-файл добавил. Это считается?

     
     
  • 7.364, DyadyushkaAU (ok), 15:55, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сколько в итоге денег сэкономили? А сколько времени ушло на то, чтобы разобраться с языком программирования вообще и конкретным драйвером в частности? СтОило оно тех усилий с экономической точки зрения?
     
     
  • 8.387, YetAnotherOnanym (ok), 16:36, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    По сравнению с каким вариантом С основами языка - около месяца на 2м курсе, лет... текст свёрнут, показать
     
     
  • 9.392, DyadyushkaAU (ok), 18:01, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    По сравнению с покупкой нового девайса, который бы работал без переделки драйвер... текст свёрнут, показать
     
     
  • 10.393, Аноним (-), 18:11, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Но как обычно - только в теории Потому что еще есть время, затраченное на поиск... текст свёрнут, показать
     
     
  • 11.396, DyadyushkaAU (ok), 19:09, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Для подавляющего большинства пользователей, не занимающихся профессионально разр... текст свёрнут, показать
     
     
  • 12.399, Аноним (-), 21:28, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Практика, которая проста только у теоретиков Если рассматривать покупки, как ... большой текст свёрнут, показать
     
     
  • 13.406, DyadyushkaAU (ok), 00:02, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И в чём здесь могут быть сложности Обычный пользователь считает, что он реально... большой текст свёрнут, показать
     
     
  • 14.407, Аноним (-), 02:00, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В расхождении подсчета на пальцах и _реального_ результата Ваш Кэп Т е мы ... большой текст свёрнут, показать
     
     
  • 15.411, DyadyushkaAU (ok), 11:17, 08/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да, пропустил, извиняюсь Но что это меняет в корне Текущее положение дел тако... большой текст свёрнут, показать
     
  • 10.394, YetAnotherOnanym (ok), 18:58, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Кто может это гарантировать заранее Плюс N денежных единиц за выкинутый старый... текст свёрнут, показать
     
     
  • 11.395, DyadyushkaAU (ok), 19:06, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно, что производитель девайса Минус амортизация Это время ничего не стои... текст свёрнут, показать
     
     
  • 12.400, YetAnotherOnanym (ok), 00:52, 07/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Разве Вам никогда не встречались устройства, производитель которых обеспечивает ... большой текст свёрнут, показать
     
     
  • 13.405, DyadyushkaAU (ok), 23:45, 07/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Встречались И Не понимаю, к чему вы клоните Напоминаю, я вступил в дискуссию ... большой текст свёрнут, показать
     
  • 5.278, Michael Shigorin с дороги (?), 17:50, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Если оно вообще будет работать, например, усб звуковухи с амдшными камнями не работали,
    > когда я в прошлый раз проверял.

    Да какие там звуковухи -- вон захотели тут давеча ноут с этой их хвалёной win10 в локалку кабелем подключить, своего Ethernet на нём не оказалось, а два оказавшихся под рукой dlink (сотка и гигабит на распространённых чипах, в линуксе что десять лет назад работали, что сейчас) -- "ой, не вижу, поискать в интернете?".

    Занавес.

     
     
  • 6.295, Смузихлёб (?), 19:31, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я человек простой, вижу шигорина, ставлю диз даже не читая.

     
  • 6.309, YetAnotherOnanym (ok), 22:38, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    IT-специалиста, способного купить ноут без eth-разъёма, надо гнать с фирмы тряпками, а не usb-адаптер ему подбирать.
     
  • 3.149, Аноним (149), 17:56, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вакцины от Windows 11 несуществует, мои соболезнования вашим родным и близким.
     
  • 3.245, pavlinux (ok), 14:23, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > По хорошему нужно раз в несколько лет переписывать всё с нуля
    > с оглядкой на актуальное железо, а не тянуть гору костылей, прослоек и надстроек.

    Рожай каждый год нового ребенка, зачем тебе старые, 2-,3-,4-,5-летние дети?

     
     
  • 4.256, Смузихлёб (?), 16:48, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Рожай каждый год нового ребенка, зачем тебе старые, 2-,3-,4-,5-летние дети?

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

     
     
  • 5.277, Michael Shigorin с дороги (?), 17:46, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > чтобы проводить подобные аналогии

    Уж не знаю, какой у _Вас_ понос вместо мозгов -- но Вас макнули носом именно в то, что порождаемый Вами и Вам подобными однодневный хлам через год уже "устарел" и нафиг никому не нужен; а то, во что действительно вложены время, силы, душа -- и через сорок лет мило и дорого.

    Не спешите отбрёхиваться.  Подрастёте -- поймёте, жизнь так устроена.

     
     
  • 6.296, Смузихлёб (?), 19:32, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > то, во что действительно вложены время, силы, душа -- и через сорок лет мило и дорого

    Именно поэтому ты сидишь на core 2 duo в 2к22 году? Мило, лол.

     
  • 2.237, DyadyushkaAU (ok), 13:23, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, хорошо, что нашёлся очередной Геракл. Но не лучше бы было просто не доводить до такого, используя более современные и адекватные языки?
     
     
  • 3.374, Аноним (330), 18:06, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А, да, святой Rust эту проблему решит на раз плюнуть.
     
     
  • 4.384, DyadyushkaAU (ok), 13:19, 06/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Может и не на раз плюнуть, но точно с меньшим количеством ошибок работы с памятью и последующей вознёй с их отловом. Плюс масса других вкусных плюшек из коробки.
     

     ....большая нить свёрнута, показать (31)

  • 1.139, ананоша (?), 17:08, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Скоро Линукс перейдет на zig и ее сборочную систему
     
     
  • 2.158, Аноним (-), 18:25, 03/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    make menuconfig тебя не одобряет.
     

  • 1.164, Аноним (164), 18:58, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >make -j96

    Лишь бы ninja не использовать.

     
     
  • 2.379, Аноним (-), 23:51, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Лишь бы ninja не использовать.

    Лучше не использовать вне локалхоста, тормозное г..но

     

  • 1.167, смешнох (?), 19:47, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Опять у сквирти обострение. Ну, хорошо что залогинился, родной.
     
  • 1.179, Аноним (180), 21:21, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > make -j96 vmlinux

    Спасибо проорался. Такое количество ядер ни одному гентушнику недоступно.  

     
     
  • 2.279, Michael Shigorin с дороги (?), 17:52, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Среди моих знакомых гентушников есть минимум один бывший админ нескольких вузовских кластеров, который и сейчас, думаю, без проблем столько получит при надобности (правда, на сервере под альтом, но это уже технические подробности). :)
     
     
  • 3.426, Аноним (426), 19:52, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не важно. Gentoo в chroot можно собирать хоть под Ubuntu, хоть под MX Linux.
     

  • 1.190, Ананоним (?), 23:19, 03/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Наконец-то кто-то хорошо показал весь бардак в исходниках ядра :) Я когда первый раз туда заглянул, очень грустно мне стало.
     
  • 1.208, iCat (ok), 07:58, 04/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    50-80%
    Это довольно свирепо...
     
  • 1.229, Аноним (229), 12:23, 04/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >ускоряющих сборку ядра Linux на 50-80%

    и че теперь делать?

     
     
  • 2.427, Аноним (426), 19:53, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Компилять
     

  • 1.244, pavlinux (ok), 14:19, 04/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Смотрю в теме одни дистростроители собрались, что не х..., то свой дистриб. А в реальности: apt upgrade. :D
     
     
  • 2.280, Michael Shigorin с дороги (?), 17:53, 04/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ...из бинарного демьяна? ;-}

    С наступившим!

     
  • 2.422, Аноним (422), 19:29, 10/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А ты сам-то кто?
     
  • 2.428, Аноним (426), 19:57, 11/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А то нет? Берёшь howto от какого-нибудь "Линукс для себя" и вперёд.
     

  • 1.254, Аноним (254), 16:38, 04/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ага, убираем поддержку rust и станет ещё быстрее.
     
     
  • 2.326, . (?), 11:31, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    да просто отключаешь в конфиге сотни ненужных тебе драйверов
     
     
  • 3.331, Аноним (330), 12:18, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да какую сотню? Один-два учебных.
     

  • 1.316, pavlinux (ok), 05:20, 05/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/

    >x86/kbuild: Enable CONFIG_KALLSYMS_ALL=y in the defconfigs
    >Most distro kernels have this option enabled, to improve debug output.
    >Lockdep also selects it.
    >Enable this in the defconfig kernel as well, to make it more
    > representative of what people are using on x86.

    Каким раком дебажная функция нужна для ускорения сборки?

     
     
  • 2.378, Аноним (-), 23:49, 05/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ты прочитал

    > to make it more representative

    как ускорение ?

     

  • 1.324, . (?), 11:26, 05/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    не усложнит ли это понимание единицы компиляции? чистка "неиспользуемых хедеров" - это хорошо. но не всякий перекрёстный нелогичен. если есть в одном хедере второй, перекрёстный тому что в юните уже есть, это не исходит из логики по умолчанию, что в первом должен быть второй. и соответственно его не уберут в будущем.
     
  • 1.372, Аноним (372), 17:07, 05/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А почему это не делается/проверяется автоматически?
     
  • 1.373, Аноним (330), 17:57, 05/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это повод увеличить мажорный номер версии.
     
  • 1.391, фстэк якобы (?), 17:54, 06/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    не взлетит. подумаешь, время компиляции. вон, раст компилируется часами, никто и в ус не дует.

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

     
  • 1.404, pavlinux (ok), 20:54, 07/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кароч, три дня трахал, компилится быстро, только не грузится. :)


     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру