Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%"	+/–
Сообщение от opennews (?), 03-Янв-22, 11:12
Инго Молнар (Ingo Molnar), известный разработчик Linux ядра и автор планировщика задач CFS (Completely Fair Scheduler), предложил для обсуждения в списке рассылки разработчиков ядра Linux серию патчей, затрагивающих более половины всех файлов в исходных текстах ядра и обеспечивающих увеличение скорости полной пересборки ядра на 50-80% в зависимости от настроек. Реализованная оптимизация примечательна тем, что она сопряжена с добавлением самого крупного в истории разработки ядра набора изменений - для включения разом предложено 2297 патчей, меняющих более 25 тысяч файлов (10 тысяч заголовочных файлов в каталогах "include/" и "arch/*/include/" и  15 тысяч файлов с исходными текстами)... Подробнее: https://www.opennet.me/opennews/art.shtml?num=56449
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+99 +/–
Сообщение от Онаним (?), 03-Янв-22, 11:12
Титанический труд, да... Очень надеюсь, что с принятием такового затягиваться не будет, потому что иначе всю работу придётся проделать второй раз.
Ответить | Правка | Наверх | Cообщить модератору

	11. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+11 +/–
	Сообщение от макпыф (ok), 03-Янв-22, 11:39
	скорее всего будут, так как проверить это все не так быстро. Придется ждать ревью от маинтейнеров всех затронутых подсистем и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+9 +/–
	Сообщение от Кирилл (??), 03-Янв-22, 12:58
	И это первый шаг. Когда разгреб первую гору навоза. Выльется ещё 10. А раньше эти 10 не замечали. Так как кто раньше уходил разгребать - не возвращался. Эффект выжившего. Теперь главное что сам линтер был написан высокоуровнево. И сам не превратился в дракона с золотыми цепями совместимости.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+9 +/–
	Сообщение от анончик (?), 03-Янв-22, 12:47
	Согласен, - чувак просто монстр!!! p\s Когда изучал libc, в частности picolibc, тоже обратил внимание, что там бардак с заголовками, + туева куча одинаковых макросов, по хорошему место которым в одном файле. Решил начать всё это рефакторить, но интузиазм быстро пропал:( - за бесплатно таким заниматься такое себе удовольствие:)) p\p\s вот что бывает когда, весь проект это по сути этакий копи-паст из других проектов, или когда нет четкого стиля для проекта, - да там, даже в одной функции можно было увидеть, что она была составлена из кусков которые писали разные люди:)))
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	89. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–14 +/–
	Сообщение от Аноним (89), 03-Янв-22, 13:53
	Конечно примут. Это же кого надо патчи.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	102. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+6 +/–
	Сообщение от опеннетовский анон (?), 03-Янв-22, 14:47
	А что, вы отправляли патчи, и их не принимали? Расскажите подробнее.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–6 +/–
	Сообщение от Аноним (186), 03-Янв-22, 22:34
	reiser4?
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–8 +/–
	Сообщение от Аноним (89), 03-Янв-22, 23:59
	Тебя простить может только что ты лежал в криосне. И сейчас пробудился. Потмоу что через один новость на опеннете о том как приняли или не приняли очередной патч. Вот Инго упоминаемый тут в ядро внес вклад.  А вот Кон не внес. Рядом рассказывают как принимают ксмбд. А недалеко уже неизвестно какой раз пытаются бить на патчи автор ваергварда. Тут же недалеко всё что было до селинуха отправили лесом. И прочая, прочая. Ты на самом деле не в курсе как это происходит уже пару десятков лет? А у комментария ещё есть прекрасный маркерок. Уровень деградации опеннетчиков.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	281. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:57
	Деградация -- это когда пытаешься судить о чём-то исключительно со слов рабиновича, музыки рабиновича?.. Если что, с моим участием в ядро патчик запихивали.  Месяца три висела бага, затем пару недель лежало письмо, потом его заметили -- и буквально за ночь в краткой переписке замержили. О том, что со сложными патчсетами нетривиальные люди могут годами стучаться (до того вложившись в их наработку) -- разумеется, тоже знаю.  Но то же ГОСТовское шифрование в ядро коллеги (точнее, vt@altlinux) вполне себе дотащили.
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (89), 05-Янв-22, 10:10
	Конечно рабиновичи мне напели. Миша уж кому-кому а тебе бы по этому поводу не говорить. Как там етцнет, втянули во все ведущие дистры? Как там кастэл с рсбаком что вы собирали, успешно применен в ядре и дистрах? Все патчи с рпм альтового уже втянули в апстрим? Как там опенволовские патчики, приняты безоговорочно? А рядом, например, ваергвард который порвали на куски и впихнули непойми как в ядро. >   Но то же ГОСТовское шифрование в ядро коллеги (точнее, vt@altlinux) вполне себе дотащили. Очень смешно. Сколько там браузеров гостовое шифрование поддерживает? Полторы калеки? Один яндексовый, второй хромиум с патчами который регулярно при пересборке перестает нормально работать.
	Ответить | Правка | Наверх | Cообщить модератору

	401. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от IRASoldier_registered (ok), 07-Янв-22, 16:40
	Гляди-ка, нашелся конспиролог круче Шигорина, хотя казалось бы, куда уж круче-то.
	Ответить | Правка | Наверх | Cообщить модератору

	408. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (89), 08-Янв-22, 04:32
	А лгать прилюдно не стыдно? Простые факты доступные для проверки всем называть конспирологией может только больной человечек. У тебя там с сознанием всё в порядке? Или ты за новогодние праздники расширил его чересчур? Так в режим пора уже входить, почитай что-нибудь умное.
	Ответить | Правка | Наверх | Cообщить модератору

	437. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от IRASoldier_registered (ok), 23-Янв-22, 01:31
	> Простые факты доступные для ...веры всем конспирологам. Поправил, не благодари.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Ordu (ok), 03-Янв-22, 21:04
	> Очень надеюсь, что с принятием такового затягиваться не будет, Будут. В описании патчсета Инго настойчиво повторяет, что это RFC, то есть request for comments от сообщества. И его дальнейшие планы на тот случай, если в целом linux выскажет готовность пойти на принятие такого -- это допиливать сие в отдельном дереве, с тем чтобы основную часть работы выполнить до мерга в мейнстрим, оставив на потом лишь ловлю блох. > потому что иначе всю работу придётся проделать второй раз. Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. Что требует конечно времени, но существенно меньше, чем можно было бы подумать. Во-вторых, есть шансы, что сейчас кто-нибудь подключится, и, допустим, пока Инго продолжает выпиливать, кто-то другой будет заниматься rebase'ами.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	232. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от qux (ok), 04-Янв-22, 13:01
	> Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. Что > требует конечно времени, но существенно меньше, чем можно было бы подумать. В таких изменениях разгребать конфликты иногда не проще создания с нуля. Когда я делал похожее в намного меньшем проекте, то автоматизировал бОльшую часть работы, иначе и ошибок было б намного больше, и переделывать надо было бы несколько раз
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (334), 05-Янв-22, 13:10
	> Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. Это ядро. Тут патчи принято приводить к нужному виду, а не коммиты таскать. Сейчас в отдельной ветке проведут ревью (уже обговорили в рассылке), протестят, подправят, оформят новым набором патчей с меньшим их числом (автор уже сказал что 70% можно в один).
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	335. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Ordu (ok), 05-Янв-22, 13:21
	>> Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. > Это ядро. Тут патчи принято приводить к нужному виду, а не коммиты > таскать. Коммиты и есть патчи, только хранимые в git.
	Ответить | Правка | Наверх | Cообщить модератору

	376. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (334), 05-Янв-22, 21:04
	> Коммиты и есть патчи, только хранимые в git. Удивительно. Только прежде чем их примут в ядро, ты десять раз переделаешь их. Именно переделаешь, а не добавишь ещё несколько коммитов.
	Ответить | Правка | Наверх | Cообщить модератору

	377. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Ordu (ok), 05-Янв-22, 23:32
	>> Коммиты и есть патчи, только хранимые в git. > Удивительно. Только прежде чем их примут в ядро, ты десять раз переделаешь > их. Именно переделаешь, а не добавишь ещё несколько коммитов. И чё?
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Семен (??), 04-Янв-22, 05:07
	Скорее всего затянется. Мне чтобы заставить работать этот набор патчей пришлось написать еще несколько своих патчей. Плюс ядро у меня ловило кернелпаник.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	315. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от pavlinux (ok), 05-Янв-22, 05:18
	....
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	398. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от жорик (?), 06-Янв-22, 21:16
	я руками собираю
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–14 +/–
Сообщение от Аноним (2), 03-Янв-22, 11:17
Почему сишники за 50 лет не догадались сделать модульную систему как в Яве? Каждый компиляйшон юнит требует парсинга сто шессот файлов. В каком нибудь Дельфи жмещь запустить - и сразу запускается
Ответить | Правка | Наверх | Cообщить модератору

	14. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+18 +/–
	Сообщение от Онаним (?), 03-Янв-22, 11:44
	Сразу видно, что серьёзных проектов на Дельфи у тебя не было :D
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+9 +/–
	Сообщение от Аноним (17), 03-Янв-22, 11:50
	Потому, Delphi компиляет отдельные юниты в отдельные независимые модули (которые даже если и лежат в итоге в одном бинарнике - по сути, как набор отдельных взаимодействующих библиотек). А "Ява" - это вообще виртуальная машина, у неё вообще никаких гарантий на время выполнения нет. Одна и та же строчка кода может работать как 1, так и 1000 единиц времени. В случае с Си, из-за того, что язык используется для системного программирования - требуются гарантии детерминированности времени исполнения кода. И если Delphi программа может позволить себе "подождать" несколько миллисекунд на то, чтобы подгрузить страницы другого модуля, инициализировать его и т.д., то если у тебя в обработчике прерывания в ядре начнёт происходить недетерминированная хрень и логика-отсебятина компилятора - то ядро просто работать не будет. В си тоже вполне себе есть "модули". Библиотеки (статические и динамические) - это именно про это. Если ты разбиваешь свой проект на отдельные незавимые библиотеки - то чаще всего их можно собирать и редактировать каждый по отдельности, и пересборка всего проекта не требуется. И даже ядро умеет динамически линковаться с кодом - kernel objects - это именно про это. Просто из-за особенностей ядерной разработки - одна правка в базовое ядро может сломать модули, собранные под старое ядро, причём самым неожиданным образом (т.к. всё работает в одном адресном пространстве, промахнулся на 1 байт в структуре - и ты уже, например, корраптишь данные файловой системы). Поэтому дешевле не портить себе нервную систему и не стрелять в ногу - так что ядро пересобирают целиком. Ну, а то, что некоторые сишники и плюсовики (например, проект Chromium) закидывают всё в один проект и делают монолитные проекты на 60 миллионов строк кода которые компиляются в районе суток - это уже проблема рук, растущих не из того места, а не языка.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	22. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от Цезий Родонович (?), 03-Янв-22, 12:01
	Что за дичь ты написал? Особенно доставило про делфи и инициализацию модулей. Некоторые недостатки других ЯП и компиляторов, никак не оправдывают конченную модульность в C/C++
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Аноним (17), 03-Янв-22, 12:14
	Потому что это именно так и устроено - каждый дельфёвый модуль - это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой набор функций и использует функции других библиотек. Т.е. ничем концептуально не отличается от проекта на си, состоящего из нескольких десятков статически слинкованных библиотек. Когда пишешь на C - тебе не приходится пересобирать каждый раз glibc с проектом. На сях обычно каждый C-файл не делают отдельной библиотекой. Во-первых, потому что растут накладные расходы, софт становится медленнее. А во-вторых, это закрывает целый ряд оптимизаций, который возможен в gcc (в том числе link-time optimization), но не возможен в Delphi, потому что МОДУЛЬНОСТЬ.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от iZEN (ok), 03-Янв-22, 12:26
	> Потому что это именно так и устроено - каждый дельфёвый модуль - > это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой > набор функций и использует функции других библиотек. Т.е. ничем концептуально не > отличается от проекта на си, состоящего из нескольких десятков статически слинкованных > библиотек. Когда пишешь на C - тебе не приходится пересобирать каждый > раз glibc с проектом. Приходится из-за детерминированности связей с обратными вызовами и LTO. В классическом Turbo Pascal и Delphi используется однопроходный компилятор без препроцессора. > На сях обычно каждый C-файл не делают отдельной библиотекой. Во-первых, потому что > растут накладные расходы, софт становится медленнее. А во-вторых, это закрывает целый > ряд оптимизаций, который возможен в gcc (в том числе link-time optimization), > но не возможен в Delphi, потому что МОДУЛЬНОСТЬ. Delphi 2 (32-bit) на Pentium II показывала скорость компиляции ~300000 строк в секунду. Это быстрее, чем Turbo C на том же оборудовании в десятки раз. Дельфишник, как правило, чтобы запустить проект на пробное выполнение, статически собирал проект вместе с VCL в автономный EXE-файл, невзирая на размеры последнего. Потому что скорость компиляции и связывания с заранее откомпилированным (бинарным, .dcu) кодом была выше, чем каждый раз пересобирать такую же по функционалу "портянку" из исходников, написанных на С/С++ Builder.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (65), 03-Янв-22, 13:20
	А теперь пойди и посмотри на классический трупопаскаль, ага. Один раз, а потом второй, но уже глазами
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Цезий Родонович (?), 03-Янв-22, 12:01
	Что за дичь ты написал? Особенно доставило про делфи и инициализацию модулей. Некоторые недостатки других ЯП и компиляторов, никак не оправдывают конченную модульность в C/C++
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	94. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (-), 03-Янв-22, 14:09
	>C/C++ Это что за язык такой?
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Аноним (122), 03-Янв-22, 16:27
	Он даже не в курсе, что это два разных языка. Просто второй скопипастил у первого, но как-то не очень уверенно и криво. Даже разные фишки выкидывать пришлось ради "святого ООП", который по факту просто макрос для вызова функций с контекстом (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях).
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 03-Янв-22, 17:01
	> restrict появился в c99 > (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях). Экспердус опеннетус вульгарис ...
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (228), 04-Янв-22, 11:58
	Это два языка. Никогда не видел перечисление косой чертой?
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	290. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–4 +/–
	Сообщение от Аноним (-), 04-Янв-22, 18:32
	В Юникс мире такого перечисления никто не знает.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (2), 03-Янв-22, 12:02
	> закидывают всё в один проект и делают монолитные проекты на 60 миллионов строк кода которые компиляются в районе суток Ну зайди в билд систему любого дистра и убедись, что неоправданно долгая компилюха - это болезнь вообще всех сишных проектов. Перейдя в Линукс, в свое время удивился, как обычный gtk.-хелловорлд компилился секунды, а не наносекунды, как в Дельфи.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	39. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (17), 03-Янв-22, 12:22
	Я гентушник, мне не надо "заходить в билд систему", она у меня прямо на компе. Я не сказал, что софт компиляется быстро. Сишные проекты действительно собираются ощутимо долго.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (2), 03-Янв-22, 12:38
	> проблема рук, растущих не из того места, а не языка. Следовательно, таки языка, а не рук.
	Ответить | Правка | Наверх | Cообщить модератору

	412. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от n00by (ok), 08-Янв-22, 19:57
	А если бы хоть раз посмотрели машинный код после кодогенератора Дельфи, то удивления бы не было.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	416. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от A.N.Onimous (?), 08-Янв-22, 23:17
	>из-за особенностей ядерной разработки Интересный эвфемизм для отсутствия архитектуры
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	18. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (18), 03-Янв-22, 11:51
	Ява же любит кушать память
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	37. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–7 +/–
	Сообщение от iZEN (ok), 03-Янв-22, 12:16
	> Ява же любит кушать память Пальму первенства по этому свойству она давно отдала Rust'у.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+5 +/–
	Сообщение от Rev (?), 03-Янв-22, 13:48
	А будут ссылки на доказательства, или ты просто балабол?
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (96), 03-Янв-22, 14:16
	Из книжки Rust: Гарантии безопасности памяти в Rust затрудняют, но не делают невозможным случайное выделения памяти, которая никогда не очищается (что известно как утечка памяти ). Полное предотвращение утечек памяти не гарантируется Rust, так же как не является гарантией отсутствие гонок данных проверенных во время компиляции, а это означает, что утечки памяти безопасны в Rust. В реальности: Так же как Java безопастный раст может схавать столько памяти, сколько ей дадут или пока не прибьют OOM киллеры, т.к. память течет.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от kai3341 (ok), 03-Янв-22, 18:37
	Давай переведу с русского на русский: разработчики Rust предупреждают, что говнокод может течь -- какая неожиданность
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от pda (ok), 03-Янв-22, 21:03
	Подождите, этот гений однажды узнает, что в Java несмотря на gc тоже возможны утечки памяти, его тогда инфаркт хватит... https://www.baeldung.com/java-memory-leaks
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от aname (?), 04-Янв-22, 12:43
	Так а зачем нам такой безопасный язык- то?
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	253. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (253), 04-Янв-22, 15:30
	Затем что невозможно избежать утечек памяти. Это как пытаться избежать языковыми средствами возможности зацикливания (проблема останова). Можно, но не будет уже полноты по Тьюрингу. Ошибка здесь такая. Вы утверждаете что ремень безопасности не уберегает от летальных случаев на дорогах и потому не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (286), 04-Янв-22, 18:06
	>Затем что невозможно избежать утечек памяти. Тогда и не надо было пыжиться, пытаясь заменить C++, Rust отличная замена сишарпа, только вот с такими приколами в нишу сишки с плюсами ему не пролезть.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (253), 04-Янв-22, 21:45
	Сишарп на виртуальной машине работает. Его сравнивать с Rust/C++/C некорректно, можно с Явой. Раст (по примеру ремня безопасности в машине) избавит от 70% эксплуатируемых уязвимостей. Напомню, что утечка памяти в программе на rust это максимум denial-of-service класс атаки. https://www.zdnet.com/article/chrome-70-of-all-security-bugs.../ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro.../
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Онаним (?), 05-Янв-22, 11:31
	На данный момент он да, избавляет от 99% эксплуатируемых уязвимостей, просто потому, что эксплуатировать нечего и негде.
	Ответить | Правка | Наверх | Cообщить модератору

	348. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 14:14
	В твоём г-нокоде - вполне возможно. Google, MS, Huawei, Mozilla, Amazon - уже эксплуатируют вовсю. Разумеется, речь не идёт о полном переписывании с нуля всего и вся, это было бы очень и очень дорого.
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (286), 04-Янв-22, 18:00
	>разработчики Rust предупреждают, что сборка мусора не работает и надо использовать костыли, а криков-то по поводу free() было...
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	308. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (253), 04-Янв-22, 21:47
	Каким образом выход за скоуп объекта с его немедленным освобождением является костылем? Проще и органичней еще ничего не придумали.
	Ответить | Правка | Наверх | Cообщить модератору

	431. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (431), 12-Янв-22, 07:20
	>разработчики Rust предупреждают, что говнокод может течь На Rust бывает другой код?
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	432. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (-), 12-Янв-22, 14:29
	>>разработчики Rust предупреждают, что говнокод может течь > На Rust бывает другой код? У тебя нет, независимо от ЯП. Но не все люди - ты.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от lufog (ok), 03-Янв-22, 14:08
	Сомнительное утверждение, учитывая что в Rust нет сборщика мусора, а ресурсы освобождаются автоматически при выходе переменной из области видимости. В теории, конечно можно оперировать сырыми указателями в unsafe блоке, и управлять памятью вручную, но это ничем не будет отличаться от того же C/C++.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	413. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от n00by (ok), 08-Янв-22, 20:05
	Удивительно, но free() не обязательно освобождает ресурсы, а всего лишь возвращает память куче. Потому, когда на "том же же C/C++" пишут специфичные для задачи менеджеры памяти, которые решают проблему фрагментации кучи, "автоматическое освобождение" течёт. А когда все переменные стековые, то получается максимум HelloWorld.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Аноним (46), 03-Янв-22, 12:33
	Когда на любой чих делают аллокацию объекта, да еще и в цикле, а потом ява виновата, а не криворукие кодеры. В джаве так-то можно JVM указать, сколько хипа она максимально может выжрать, прежде чем с ООМ грохнется.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	170. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от лютый жабби__ (?), 03-Янв-22, 21:03
	>В джаве так-то можно JVM указать, сколько хипа она максимально может выжрать и как это опровергает фразу "жаба жрёт ОЗУ как свинья помои"? Погугли сколько памяти в жабе занимает Double или Integer ) И, кстати, делать 100500 одноразовых иммутабельных объектов (и массово заниматься их копированием с места на место) - это прямая рекомендация от корифеев многопоточного погромирования на жабе )
	Ответить | Правка | Наверх | Cообщить модератору

	357. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (46), 05-Янв-22, 14:50
	Иммутабельность позволяет получить дешевую в поддержке потокобезопасность. Никто не пойдет ковыряться в проекте, где мьютекс на мьютексе и семафором погоняет. Ну может за ОЧЕНЬ большие деньги. А так как у иммутабельных объектов нет стейта, их можно закешировать в пул и возвращать одну и ту же сцыль. Так что все проблемы с аллокацией снова от криворуких кодеров, не могущих в педантичное переиспользование того, что можно переиспользовать. Про Flyweight паттерн еще GoF писали. P.S. А классы-обертки везде использовать тебя никто не заставляет. "Нормально делай - нормально будет." (с)
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (27), 03-Янв-22, 12:07
	Тем временем не только лишь каждый Java проект размером на 3 порядка меньше собирается быстрее, чем за 130с.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	153. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (153), 03-Янв-22, 18:04
	Настоящий Java проект только на скачивание артифактов трати больше чем 120 сек
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от мое правило (?), 03-Янв-22, 23:25
	У нас серверок был, логики не очень много и полностью кастомная, на джава. И там были зависимости на апач либы разной бигдата направленности. И эта помойная параша без локального кеша с быстрого прокси в сети качала зависимости 1.5 часа. Оно писало сотни тысяч мелких и больших файликов, делало миллионы запросов на ьедное прокси. С локальным кешом собиралось 30 минут. Что бы не страдать во время локального девелопмента я на начале спринта регулярно запускал скрипт, который собирал свежие зависимости и хардкодом записывал их во все возможные анналы класспаса, и чистил зависимости. Таким образом сборка кода и артефактов для установки занимала 10 минут.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Аноним (35), 03-Янв-22, 12:15
	> В каком нибудь Дельфи жмещь запустить - и сразу запускается С Бейсиком не попутали?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	113. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от OpenEcho (?), 03-Янв-22, 15:49
	Да и не с каждым Бейсиком прокатит, Power Basic к примеру тоже компилировать сперва прийдется
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (161), 03-Янв-22, 18:43
	Кстати разработчики Delphi реально всегда выпячивали скорость компиляции, как главное преимущество над C++. Явное разделение интерфейса и имплементации позволяло делать очень быстрые однопроходные компиляторы.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	194. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Аноним Максим (?), 03-Янв-22, 23:26
	На момент выхода Делфи скорость компиляции равноценных проектов переписанных с Си действительно отличалась на порядки, но это ж было аж на 386 процессорах и жесткими дисками даже без DMA. В то время и я писал на Делфи не смотря на паталогическое неприятие Паскаля. Логично, когда скорость компиляции Делфи на реальных проектах перестала быть ключевой особенностью, а среда разработки закостенела, тут от нее массово и отказались.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (96), 03-Янв-22, 12:52
	Тормозное выполнение с гигабайтами памяти или тормозная сборка? что важнее конечному пользователю эклипса, андроида и прочих тормозных продуктов ява мира? Но на пользователей уже всем плевать, хренак хренак в продакшн и лишь бы побыстрее. потом просто сменим обои, кнопки - главное есть видимость улучшения.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	53. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Аноним (53), 03-Янв-22, 12:52
	Потому что, когда придумывали Си, не было гигабайтов памяти. И даже мегабайтов не было.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	56. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от iZEN (ok), 03-Янв-22, 12:57
	> Потому что, когда придумывали Си, не было гигабайтов памяти. И даже мегабайтов не было. Си придумали как заменитель ассемблера (который на каждой машине в 1970-х годах был свой), чтобы перенести Unix с одной машины (устаревающей не по дням, а по часам) на новую машину. "Быстро и грязно" — было в порядке вещей для C того времени.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+8 +/–
	Сообщение от Аноним (68), 03-Янв-22, 13:23
	>"Быстро и грязно" — было в порядке вещей для C того времени. это и сейчас в порядке вещей, для всего
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от DyadyushkaAU (ok), 04-Янв-22, 13:00
	Не надо преувеличивать. Может вы и не заметили, но некоторые вещи меняются к лучшему. Возьмём, к примеру, Rust. Там и модули есть, и с памятью работа корректная. Хотя некоторые программисты на Си к грязи настолько привыкли, что уже и не замечают, как они по макушку в ней увязли. Для них это уже естественное состояние. А потом появляются Геркулесы (наподобие того, что в новости) и пытаются хоть как-то расчистить то, что накопилось.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (68), 04-Янв-22, 13:37
	>Возьмём, к примеру, Rust. Никто не преувеличивает. Раст мог выйти в 2030 году проработанным и стандартизированным, но такого хайпа он мог уже и не поднять и остался бы без поддержки. Но его сляпали быстро и грязно, а теперь постепенно допиливают. В каждой новой версии старая грязь остается во имя обратной совместимости. Спорить насколько "грязно", я не буду.
	Ответить | Правка | Наверх | Cообщить модератору

	366. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 16:04
	В каждой новой версии старая грязь остаётся только... в старой редакции. Другими словами, это настраиваемо, хочешь ли ты тащить эту грязь в свой новый проект (для какой-то обратной совместимости), или ограничишься свежайшей редакцией. Поэтому можно смело заявлять, в Rust НЕТ грязи. https://habr.com/ru/post/557460/
	Ответить | Правка | Наверх | Cообщить модератору

	380. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Аноним (380), 06-Янв-22, 00:11
	вы каждый день начинаете новый проект? ;) Ваш проект тоже может быть сделан быстро и грязно и у вас сейчас полно других более насущных проблем, чем настраивать концентрацию расто-грязи. Да даже то, что раст использует llvm говорит об упомянутом подходе -- это было быстро, т.к. взяли готовое и в то же время грязно, т.к. всякие достоинства раста на это готовое не распространяются
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 06-Янв-22, 13:17
	> Ваш проект тоже может быть сделан быстро и грязно и у вас > сейчас полно других более насущных проблем, чем настраивать концентрацию расто-грязи. Причём здесь какой-то отдельной взятый проект? В случае с C, C++ вы по умолчанию тащите весь накопленный "багаж знаний" компилятора. Rust же вас ограничивает в этом багаже: вы в одном и том же коде не можете применять разные техники и разные стандарты, как в случае с C++. О какой "расто-грязи" в таком случае вы вообще говорите? > Да даже то, что раст использует llvm говорит об упомянутом подходе Смешались в кучу кони, люди. Причём здесь LLVM? -- > это было быстро, т.к. взяли готовое и в то же время грязно, т.к. всякие достоинства раста на это готовое не распространяются Ему и не надо распространяться. Компилятор Rust надаёт вам по рукам ДО ТОГО, как дело дойдёт до компиляции в машинный код.
	Ответить | Правка | Наверх | Cообщить модератору

	389. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (68), 06-Янв-22, 17:08
	> В случае с C, C++ вы по умолчанию тащите весь накопленный "багаж знаний" компилятора. не-а — у меня лишь нет препятствий тащить > О какой "расто-грязи" в таком случае вы вообще говорите? о той, которую надо или переписывать, или она вынуждает привязываться к редакции. Если все всё могут переписать, то смысла в редакциях особо нет > Смешались в кучу кони, люди. Причём здесь LLVM? он ведь все еще используется? Ну там "Rust compiles to LLVM" и т.п. > Компилятор Rust надаёт вам по рукам ДО ТОГО, как дело дойдёт до компиляции в машинный код. а мне не нравится, что Rust не надавал по рукам тем, кто писал реализации алгоритмов оптимизации и компиляции/трансляции в машинный код. Идеальный, чистый и проверенный код на расте обрабатывается грязным бэкендом, который в результате может добавить непонятных и трудноотлавливаемых ошибок PS: мы начали с того, что вам не понравилось мое общее высказывание по поводу "быстро и грязно" >Не надо преувеличивать. Может вы и не заметили, но некоторые вещи меняются к лучшему. Возьмём, к примеру, Rust… 1. я так же заметил, что многие вещи меняются к лучшему во многих областях (языках, проектах) и даже C/C++ тут не исключение 2. понятия "нормы" или "грязи" меняются или, что еще хуже, они хорошо сдобрены маркетинговой чепухой. Сейчас ведь стало нормой писать жручие и падучие приложения, т.к. "контейнер в облаке перезапустится в N миллисекунд" или "планка памяти стоит как две чашки кофе" — программисты прошлого схватились бы за голову от такого. 3. "грязь" есть везде: где-то из-за незнания или неопытности, где-то из-за недостатка времени. Про то, что спорить про ее концентрацию я не намерен я уже писал 4. больше ни слова про раст и c/c++ :)
	Ответить | Правка | Наверх | Cообщить модератору

	390. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 06-Янв-22, 17:53
	> не-а — у меня лишь нет препятствий тащить О чём я и говорил ранее. Программисты увязли по макушку в грязи, и этого не замечают. :) > о той, которую надо или переписывать, или она вынуждает привязываться к редакции. Если все всё могут переписать, то смысла в редакциях особо нет Подмена понятий, ясно-понятно. > он ведь все еще используется? Ну там "Rust compiles to LLVM" и т.п. Да. И? > а мне не нравится, что Rust не надавал по рукам тем, кто писал реализации алгоритмов оптимизации и компиляции/трансляции в машинный код. Идеальный, чистый и проверенный код на расте обрабатывается грязным бэкендом, который в результате может добавить непонятных и трудноотлавливаемых ошибок Есть конкретные претензии? Или так, теоретизируем? Но допустим, что есть. Если вы чем-то недовольны, всегда можно сообщить об этом соответствующей команде. А кто конкретно будет решать найденную вами проблему (команда Rust или команда LLVM), какая уже разница? > 1. я так же заметил, что многие вещи меняются к лучшему Это не вы заметили. Это я заметил. > 2. понятия "нормы" или "грязи" меняются или, что еще хуже, они хорошо сдобрены маркетинговой чепухой. Меняются, да. Но не в сторону полных противоположностей, как вы, видимо, пытаетесь представить. > Сейчас ведь стало нормой писать жручие и падучие приложения Только там, где стоимость программиста сильно выше получаемого от его квалификации эффекта. Вы же не думаете, что программирование - это сферический конь в вакууме, искусство ради искусства?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от fsb4000 (?), 03-Янв-22, 13:31
	В С++ сделали модули. Лишь слегка медленнее чем fpc...
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	160. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от kai3341 (ok), 03-Янв-22, 18:42
	Точно сделали? Там модули год назад всё порывались принять в стандарт да не приняли. Дальше я не следил Или речь о динамически линкуемых библиотеках?
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от fsb4000 (?), 03-Янв-22, 21:44
	модули приняли в С++20, а скоро уже С++23 выходит
	Ответить | Правка | Наверх | Cообщить модератору

	435. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (435), 15-Янв-22, 15:56
	> модули приняли в С++20, а скоро уже С++23 выходит Ага. В таком виде, в котором они никому не уперлись. С includ'ами был одна проблема. При перекрестных вызовах методов из двух деревьев невозможно реализовать виртуальные методы возвращающие указатели нужного типа а не базовых. В модулях это было бы сделать можно, но !!! Эти, на всю голову больные люди, предусловием поставили отсутсвие перекрестых ссылок в модулях. Занавес!
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от nc (ok), 03-Янв-22, 23:21
	Насколько я понимаю, 50 лет назад были маленькие объемы оперативки. А модульность подразумевает компиляцию сразу всех файлов модуля в единое синтаксическое дерево, что позволяет вообще отказаться от include в рамках одного модуля (именно так в C# и Java). Далее, для каждого модуля определяется публичный интерфейс и приватная реализация, и интерфейсы всех модулей проекта должны быть в оперативке (в виде AST) всегда - только так можно избежать постоянной перекомпиляции инклудов (когда один инклуд подключен в тысячи файлов и перекомпилируется тысячи раз вместе с каждым исходником). Вероятно, когда оперативка измерялась килобайтами, сделать все это было затруднительно. В Си решили поступить по простому - сделали псеводмодульность вручную, т.е. заголовочный файл - это написанный вручную публичный интерфейс. Ну и попались на этом - объемы оперативки стали расти, объемы кода тоже, переписывать язык и весь код уже было нереально, "работает - не трожь" и тому подобное. Кривизна этого подхода особенно явственно вылезла в С++, который унаследовал инклуды Си, а в заголовочные файлы стали пихать шаблонный код.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	200. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Ordu (ok), 04-Янв-22, 00:16
	> модульность подразумевает компиляцию сразу всех файлов модуля в единое синтаксическое дерево Не, как я понимаю, не подразумевает. Если ты, компилируя модуль, будешь генерировать файл типа "скомпилированный модуль", который будет что-то типа комбинации сишных .o и .h, но подчёркнуто бинарным, чтобы можно было бы быстро оттуда в оперативку вытащить декларации и перегнать их во внутреннее представление, используемое компилятором, то... А если ты ещё дашь возможность импортировать не только модуль целиком, но и частями, типа: use std::io::{Read, Write}; то тогда можно из скомпилированного модуля извлекать не все декларации, а только нужные, экономя не только время на жонглирование ими, но и оперативку под их хранение. Интересности возникнут с inline-функциями и с параметризацией, потому что для первых придётся сохранять в файл либо исходный текст и каждый раз по-новой разбирать в AST, либо сохранять в файл в каком-то предкомпилированном виде, может даже в виде AST. С параметризацией примерно то же, но ещё жёстче, потому что с inline'ами можно сделать грязно, скомпилировав их в бинарный блоб инструкций и сопроводив метаинформацией для линковки этого блоба в вызывающую функцию -- таким образом оптимизации проводимые на AST не удастся проводить над кодом после того, как функции заинлайнены, но, по-крайней мере, накладные расходы на вызов можно снять. Но с параметризацией так уже не выйдет. Но, как бы это сказать, во-первых, проблема с инлайнами не является непреодолимой проблемой даже на 64Kb оперативки, просто взгеморроиться надо, а параметризацию по типу тогда всё равно не делали, то есть её проблемы можно игнорить. А во-вторых, в C из 70-х не было inline-функций. Правда вместо них были макросы. Паскаль разрабатывался на несколько лет позже чем C, и он вполне справлялся с модулями. ТурбоПаскаль в начале 80-х вышел и работал на тех PC, в которых не было никаких мегабайт оперативки, и я не думаю что в этих PC было больше оперативки чем в PDP-11, на котором создавался C и Unix. Скорее даже наоборот. Это сейчас модульность реализуют так, чтобы хранить в оперативке дохрена гигабайт AST. Но это, как я понимаю, делается с целью выполнить максимум оптимизаций на уровне AST, то есть там, где у компилятора больше всего семантической информации, и где больше возможностей для оптимизации. А в 70-е... какая оптимизация, ты о чём?
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (201), 04-Янв-22, 01:24
	Это и так можно делать, достаточно не держать в инклюдах ничего кроме объявлений и порезать использование шаблонов. Но все равно не поможет, так как хотелось бы чтобы линкер пооптимизировал код между объектниками всякими LTO, PGO а может и BOLTом.
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

	375. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (375), 05-Янв-22, 19:36
	Ява вообще тут не к месту переплетена, тут она работает как многие динамические языки лениво подгружая зависимости по мере необходимости. Когда есть обращение к классу, этот класс ищется в загрузчике классов (в памяти JVM), если не найден,  то он ищется в classpath. В том числе по этому "java тормозит", она лениво подгружается после холодного старта, а всякие программки на go и c стартуют практически моментально (когда не требуют загрузки ресурсов с дисков).
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
Сообщение от Аноним (3), 03-Янв-22, 11:22
Больше патчей для линукса всем пользователями линукса!
Ответить | Правка | Наверх | Cообщить модератору

	40. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (40), 03-Янв-22, 12:23
	Нет нет! не надо нам патчей пиши лучше отличный безглючный код.И лучше на асемблере.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (209), 04-Янв-22, 08:20
	А сопровождать его (код на ассемблере) под каждую архитектуру, ты будешь?
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (40), 04-Янв-22, 09:53
	Да я буду сопровождать! Принимаю доллары фунты йены евро.А вы как думали за качественный код на ассемблере надо платить.Привыкли при комуннистах бесплатно.Очнитесь.
	Ответить | Правка | Наверх | Cообщить модератору

4. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
Сообщение от BratishkaErik (ok), 03-Янв-22, 11:23
Аля гентушники
Ответить | Правка | Наверх | Cообщить модератору

5. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–20 +/–
Сообщение от iZEN (ok), 03-Янв-22, 11:28
А всё от того, что в С/С++ нет МОДУЛЬНОСТИ языка Pascal.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–18 +/–
	Сообщение от Ananima (?), 03-Янв-22, 11:37
	Уже есть, но ваш этот спагетти-Linux уже никто не будет в состоянии переписать. Его изначально надо было писать нормально, а там за него первый взялся уже аутист-социофоб в очках, поэтому ядро обречено быть таким монстром
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Schwonder Reismus (?), 03-Янв-22, 11:41
	Другие варианты есть?
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от iZEN (ok), 03-Янв-22, 12:27
	> Другие варианты есть? Микроядерность.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (65), 03-Янв-22, 13:24
	Смешно
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от pofigist (?), 03-Янв-22, 13:34
	Грустно. Микроядерность требует хорошего проектирования архитектуры, что невозможно в опенсорце
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Gogi (??), 03-Янв-22, 13:47
	Ну тык Танненбаум же читал курс лекций именно по микроядерности!! Трольвадс в это время на дзюдо ездил ш_т_о_л_е??
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от pofigist (?), 04-Янв-22, 00:10
	Какое дзюдо... Видимо - за пивом и пиццей. Проблема в том что на х86 тех лет - классическая микроядерная архитектура работало медленно. Правда это решалось, но... Для этого сначала надо спроектировать, а потом - кодить. А не наоборот. Для студента-недоучки - слишком сложно. И кстати тогда появилось куча микроядерных проектов, но высокий порог вхождения - оставил их без разработчиков.
	Ответить | Правка | Наверх | Cообщить модератору

	340. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от uis (ok), 05-Янв-22, 13:52
	Hurd
	Ответить | Правка | Наверх | Cообщить модератору

	361. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от pofigist (?), 05-Янв-22, 15:37
	И? Каковы итоги?
	Ответить | Правка | Наверх | Cообщить модератору

	415. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от A.N.Onimous (?), 08-Янв-22, 23:14
	L4. Лайнокс можно оставить на какое-то время, как рантайм
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	433. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (433), 12-Янв-22, 20:58
	И почему же дипломированный аноним до сих пор не утёр "студенту-недоучке" нос? > тогда появилось куча микроядерных проектов, но высокий порог вхождения - оставил их без разработчиков И прекрасно. Уж лучше доступная людям несовершенная архитектура, чем совершенная, но понятная лишь одному академику.
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	282. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 18:00
	Ну почему, возможно -- просто остаётся академическими упражнениями обычно. При попытке выйти в реальный мир вдруг внезапно чуточку оказывается, что комбинаторику неглупые люди описывали (и, может, даже преподавали прослушавшим курс). Потом бегают юные бздишники-джависты-велосипедисты и рассказывают всем про настоящиеъ серебряные пули :)
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	320. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от pofigist (?), 05-Янв-22, 09:22
	Хорошо. Назови мне грамотно спроектированное опенсоурс5ое решение. И желательно - чтоб изначально оно не было закрытыми исходниками, которые отдали в опенсорц.
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (321), 05-Янв-22, 09:33
	Postfix, nginx, PostgreSQL, Hadoop, почти всё связанное с кластерами.
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от pofigist (?), 05-Янв-22, 10:26
	И где в этом списке грамотно спроектированные продукты?
	Ответить | Правка | Наверх | Cообщить модератору

	425. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 11-Янв-22, 17:04
	Ну и сиди на apache
	Ответить | Правка | Наверх | Cообщить модератору

	414. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от n00by (ok), 08-Янв-22, 20:46
	STL Степанова и Ли.
	Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

	227. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от iskrim (?), 04-Янв-22, 11:58
	Моя ты лапочка, что же с тобой сделали
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	119. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от qsdg (ok), 03-Янв-22, 16:05
	Так Линус же всегда сам говорил, что: "микроядро лучше чем его монолит. но монолитный линукс уже готов, а ваш юникс ещё на горизонте". Скорость разработки, как обычно.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	168. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–4 +/–
	Сообщение от Аноним (168), 03-Янв-22, 21:01
	ты вообще понятия не имеешь о чем говоришь.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Anonnnym (?), 03-Янв-22, 11:41
	В C++ есть модули. С разморозкой Вас
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	19. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Ananima (?), 03-Янв-22, 11:52
	В GCC с адовыми костылями включаются, в QtCreator'е они не появятся никогда, в Visual Studio у них не работает IntelliSense. Не нужно рассказывать о том, что не будет юзаться ещё очень долгое время. Новые проекты будут писАться на чём угодно, но только уже не на плюсах. Плюсы -- это легаси, пора это принять.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Аноним (124), 03-Янв-22, 16:39
	Народ, для чего вы постоянно выделяете букву "а" в слове "писáться", как будто из контекста не понятно о чём идёт речь?
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (182), 03-Янв-22, 21:30
	По той же причине, что и слово «бóльшее», где даже контекст не важен.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (380), 03-Янв-22, 23:24
	видел такое насчет "большая", а вот про "большее" как-то не встречал.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от Enamel (ok), 03-Янв-22, 11:53
	Формально есть, для галочки, но фактически хорошо, если к 2030 будет реально использоваться. 1. Сейчас не все даже C++14/7 используют, не говоря уже о C++20. 2. Поддержка основными компиляторами всё еще частичная со звёздочками: https://en.cppreference.com/w/cpp/compiler_support 3. Пока большинство проектов перейдет на модули, пройдет очень много времени. 4. Навсегда останется легаси, которое этого не сделает.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	341. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 13:56
	GCC впереди планеты всей, а рядом шланг
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Прохожий (??), 04-Янв-22, 10:58
	А Линукс на C++ написан?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	243. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Anonnnym (?), 04-Янв-22, 14:19
	> А Линукс на C++ написан? Нет, но это не противоречит тому факту, что в C++ есть модули
	Ответить | Правка | Наверх | Cообщить модератору

	369. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 16:57
	Оно-то не противоречит, конечно. Только в контексте обсуждаемой новости - абсолютно бесполезное новшество для Линукса.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (122), 03-Янв-22, 16:35
	Моё ядро с подключаемыми в рантайме модулями передаёт вам привет. Так же, как и все dll-ки/so-шки. Или вы бредите идеей того, что в Си ничего нету и он не менялся с момента его создания? По такой логике питон — самый продвинутый ЯП, несмотря на то, что это просто навороченный калькулятор, у которого GIL — не баг, а фича, причём «невероятно полезная и крутая».
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	141. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (-), 03-Янв-22, 17:13
	> Моё ядро с подключаемыми в рантайме модулями передаёт вам привет. Так же, > как и все dll-ки/so-шки. Или вы бредите идеей того, что в > Си ничего нету и он не менялся с момента его создания? Очередного опеннетного экспертуса не смущает, что модули могут быть на других ЯП. т.е. нахваливаемая им "модульность" - совершенно не на уровне языка, со всеми вытекающими проблемами оптимизации и вынужденными "костылями" вида LTO. > По такой логике питон — самый продвинутый ЯП, несмотря на то, что это просто навороченный калькулятор, у которого GIL Спрыги на унылую демагогию — самый продвинутый навых экспертусов, несмотря на то, что это просто бессмысленное и беспощадное сотрясание клавиатуры.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от uis (ok), 05-Янв-22, 13:36
	И с каких пор LTO стал костылём модульности
	Ответить | Правка | Наверх | Cообщить модератору

6. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
Сообщение от Аноним (6), 03-Янв-22, 11:30
j96? дайте мне такую машину
Ответить | Правка | Наверх | Cообщить модератору

	15. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Онаним (?), 03-Янв-22, 11:48
	-j96 ныне - это ещё так себе машина, всего лишь 48 ядер и 2 треда, какой-нибудь EPYC 7643, или дуалка из младших эпиков/тредрипперов. Ныне даже несервеный Threadripper 3995WX - это -j128 :D А дуалка из эпиков может и -j256 оказаться.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–5 +/–
	Сообщение от Аноним (40), 03-Янв-22, 12:13
	А вы пробовали затестит стабильность бинарника на выходе 100500 ядер.Думаю что нет.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Аноним (46), 03-Янв-22, 12:58
	Если параллелизация на уровне Make, то со стабильностью ниче не будет (как повлияет на стабильность одновременная компиляция независимых исходников?). Реальные проблемы при сборке - это то, что сами Makefile-ы написаны отстойно, т.е. могут отсутствовать правила, указывающие правильную очередность сборки, в результате чего можно влет получить состояние гонки, когда с первой попытки не соберется, а со второй - вполне себе. Да и еще про закон Амдала забывать нельзя о теоретическом пределе ускорения при параллелизации.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (40), 03-Янв-22, 13:33
	Я просто поднял тему про которую никто особо здесь не говорит не более.Может я недоконца обозначил проблему и выразился точнее каюсь да.Это вопрос мы в компании изучали при разработке промышленного по и в том числе для космоса и как не странно проблема имела место быть.Это было исследование на предмет расспараллеливания кода при компиляции на 100500 процессоров и как это влияет на конечную стабильность работы программ после сборки и запуске на реальном оборудовании.Баги и странное поведение работы программ наблюдалось в итоге.А так да причины могут быть разные.Умничать все умеют в комментах а в реале героев которые ответят за упавший спутник связи из-за не понятных глюков софта не наблюдается чуть что бежать.Как помню фобос-грунт так и профукали где же вы были умные дяди минусаторы с форума чтож вы гении не приложили свой большой ум.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (46), 03-Янв-22, 14:27
	Тут нужно смотреть контекст. Спутники и ракеты - это дорого и жалко терять, поэтому софт для них должен быть математически(!) верифицирован. Линукс же и его стабильность особо не волнует в контексте того, что тебе просто нужна серверная ОС, которая будет крутить твой интернет-сервис. Поэтому ну ничего удивительного, что сделали статистический анализ зависимости количества багов от параллелизации и нашли корелляцию. Как бы правильно разрабатывать комплексные параллельные системы ОЧЕНЬ сложно. Тут как с управлением автомобилем - даже на небольшой скорости есть шанс погибнуть в ДТП, но при соблюдении ПДД, своевременном техническом обслуживании и использовании ремней (и рабочих подушках) этот шанс ощутимо снижается. Поэтому все пользуются автотранспортом, т.к. риски приемлемые.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Криптоханыга (?), 03-Янв-22, 17:20
	>> Поэтому все пользуются автотранспортом, т.к. риски приемлемые. И боятся летать на самолетах, где реальный риск ниже...
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (205), 04-Янв-22, 05:46
	>> на самолетах, где реальный риск ниже Звездёж статистический На км пути риск ниже На поездку выше и сильно
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от www2 (??), 04-Янв-22, 10:13
	Ну да, ну да. Именно поэтому, если происходит авария с каким-нибудь самолётом, об этом во всех новостях трубят. А информацию про автомобильные аварии приходится искать где-то в закромах сайта ГИБДД. Вот информация с сайта ГИБДД за 3 января 2022 года: АВАРИЙНОСТЬ НА ДОРОГАХ РОССИИ ЗА 03.01.2022 ДТП     202 Погибли     30 Погибло детей     0 Ранены     316 Ранено детей     47 И вот информация с сайта Межгосударственного Авиационного комитета за весь прошлый год (всего за год погибло 78 человек, не разбираюсь в моделях воздушных судов, но по-моему подавляющая часть аварий приходится на малую авиацию): Дата     Место происшествия     Тип ВС     Эксплуатант     Ущерб 27.12.2021     в районе населенного пункта Азино Удмуртской Республики     Ми-2 RA-15671     АО "Казанское авиапредприятие"      Погибших: 1 (данные уточняются) ВС разрушено 10.12.2021     на границе Иркутской области и Республики Бурятия     IAR-316 RA-1881G     Частное лицо      Без жертв ВС разрушено 10.12.2021     на границе Кемеровской области и Республики Хакасия     Robinson R66 RA-07397     ООО "Кустард"      Погибших: 1 ВС повреждено 25.11.2021     на удалении 26 км от н. п. Покачи (ХМАО)     Ми-2 RA-20406     АО "Авиакомпания Конверс Авиа"      Без жертв (данные уточняются) ВС уничтожено 03.11.2021     в районе аэродрома Иркутск     Ан-12БК EW-518TI     ОАО «Авиакомпания Гродно»      Погибших: 9 ВС разрушено 24.10.2021     в районе аэродрома Ватулино Московской области     А-22ЮС RA-1242G     Частное лицо      Погибших: 2 ВС уничтожено 17.10.2021     в районе озера Балхаш Алматинской области Республики Казахстан     Cessna-182T RA-67213          Без жертв ВС повреждено 03.10.2021     в районе н. п. Лыткарино Московской области     Robinson R44 RA-04172     Частное лицо      Погибших: 3 ВС разрушено 22.09.2021     при облете радиотехнических средств аэродрома Хабаровск (Новый)     Ан-26 RA-26673     ЗАО «Летные проверки и системы»      Погибших: 6 (данные уточняются) ВС разрушено 16.09.2021     в районе озера Глубокое Советского района (ХМАО)     Белый лебедь RA-1815G     Частное лицо      Погибших: 2 ВС разрушено 13.09.2021     между селами Бехтеевка и Соколовка Прохоровского района Белгородской области     ПЗЛ-101А RA-2388G     Частное лицо      Погибших: 1 ВС уничтожено 12.09.2021     в районе посадочной площадки Казачинск (Иркутская область, Ленский район)     Л-410 RA-67042     ООО «Аэросервис»      Погибших: 4 (данные уточняются) ВС разрушено 23.08.2021     на посадочной площадке Ивановской ОКБ     ANSAT RA-20059     ООО АК «РусАвиа»      Без жертв (данные уточняются) ВС повреждено 23.08.2021     в районе н. п. Черкизово г. о. Коломна Московской области     Borey BL010 RA-3042G          Без жертв (данные уточняются) ВС повреждено 12.08.2021     районе кордона Озерный Курильского озера (Камчатский край)     Ми-8Т RA-24744     ООО АК "Витязь-Аэро"      Погибших: 8 ВС разрушено 24.07.2021     в районе аэродрома Калинка Хабаровского края     P-2002 Sierra RA-2329G     Частное лицо      Погибших: 2 (данные уточняются) 16.07.2021     в Бакчарском районе Томской области     AN-28 RA-28728     ООО «СиЛА»      Без жертв Значительные повреждения ВС 08.07.2021     в районе аэропорта Толька (Ямало-Ненецкий АО)     P2002-JF RA-01865          Нет данных Значительные повреждения ВС 06.07.2021     в районе аэродрома Палана     Ан-26Б-100 RA-26085     АО «Камчатское авиационное предприятие»      Погибших: 28 ВС уничтожено 30.06.2021     в р-не н.п. Лыткарино Московской области     HARMONY LSA RA-2086G     ОАО НПП «Звезда» им. ак. Г.И. Северина»      Без жертв Значительные повреждения ВС 27.06.2021     в районе горы Ай-Петри Республики Крым     Robinson R44 RA-04247          Без жертв ВС повреждено 24.06.2021     РФ, Краснодарский край, Славянский район, 3.5 км западнее н. п. Забойский     Ан-2 RA-01430     ИП Заболотный Александр Александрович      Без жертв ВС частично разрушено 24.06.2021     в районе населенного пункта Яренск Архангельской области     Па-28 Арчер RA-2786G          Без жертв ВС уничтожено 19.06.2021     в Суземском районе Брянской области     СОЛОВЕЙ RA-0598A     Частное лицо      Без жертв Значительные повреждения ВС 17.05.2021     в р-не острова Мудьюг Архангельской области     Robinson R66 RA-06358     Частное лицо      Погибших: 1 (данные уточняются) ВС разрушено 09.05.2021     в р-не н.п. Калейкино Альметьевского района Республики Татарстан     Ермак RA-2994G     Частное лицо      Погибших: 2 08.05.2021     РФ, Камчатский край, г. Петропавловск- Камчатский, в районе озера Синичкино     Ми-2 RA-15715     АО «Озерновский РКЗ № 55»      Погибших: 2 ВС уничтожено 23.04.2021     РФ, Иркутская область, Черемховский район, 1.5 км юго-восточнее н. п. Рысево     N-65 RA-2722G     Частное лицо      Погибших: 2 ВС разрушено 17.04.2021     в районе населенного пункта Ильский Краснодарского края     Ми-2 RA-20977     ООО «МАЛ-АВИА»      Погибших: 1 (данные уточняются) ВС разрушено 23.02.2021     в р-не п.п. "Песь" Новгородской области     Robinson R66 RA-06201     ООО "Авиакомпания "Баркол"      Без жертв Значительные повреждения ВС 08.01.2021     Россия, Ленинградская область, Ломоносовский район, район посадочной площадки Гостилицы     РОККИ RA-2659G     Частное лицо      Погибших: 3 ВС разрушено
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от pavlinux (ok), 04-Янв-22, 14:35
	> но по-моему подавляющая часть аварий приходится на малую авиацию Там даже не малая, а частная. в основном 2-х местные пропеллерные или вертолёты типа Робинсон. Лицензию на Робинсон можно получить за 3 месяца. На нормального пилота, минимум, 6 лет учатся! Допуск к полетам через 10 лет, из них лет 5 пролетаешь как второй пилот.
	Ответить | Правка | Наверх | Cообщить модератору

	289. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 18:13
	На http://vz.ru бывают сообщения и по авиа-, и по авто-, и по железнодорожным да судоходным катастрофам и крупным инцидентам -- если "Ваше" СМИ отличается в этом плане избирательностью, подумайте, за кого оно Вас держит. Лично я до сих пор знаю только убитых и покалеченных в результате автокатастроф -- думаю, в том числе по причине гораздо более низкого порога вхождения и приличных шансов за первые же два года, почуйствовав себя "уже мастером", уже натворить бед. (впрочем, make -j тут вроде бы напрямую ни при чём)
	Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

	438. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от www2 (??), 28-Янв-22, 09:54
	> На http://vz.ru бывают сообщения и по авиа-, и по авто-, и по > железнодорожным да судоходным катастрофам и крупным инцидентам -- если "Ваше" СМИ > отличается в этом плане избирательностью, подумайте, за кого оно Вас держит. О том и речь, что автомобильные аварии случаются гораздо чаще и интересуют СМИ лишь в исключительных случаях. Если они о каждой автомобильной аварии будут писать, то остальные новости в них растворятся. > Лично я до сих пор знаю только убитых и покалеченных в результате > автокатастроф -- думаю, в том числе по причине гораздо более низкого > порога вхождения и приличных шансов за первые же два года, почуйствовав > себя "уже мастером", уже натворить бед. Именно. > (впрочем, make -j тут вроде бы напрямую ни при чём)
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от мое правило (?), 03-Янв-22, 23:30
	Емм, что вы там собираете? А ниче такого, что нормальные компиляторы выдают одинаковый разультат(побитово) в бинарниках?
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	248. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от pavlinux (ok), 04-Янв-22, 14:42
	> Емм, что вы там собираете? А ниче такого, что нормальные компиляторы выдают > одинаковый разультат(побитово) в бинарниках? Ну ты сам-то понял, что это коммент полного лoxа?
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от keydon (ok), 04-Янв-22, 17:02
	Я тоже некоторое время поработал в шаражке запускающей спутники(внезапно даже успешно). Сильная бюрократия, слабая квалификация и бесконечноеь чинопочитание преобладающее над знаниями и умениями были на каждом шагу. В основном там работали либо маразматики 80+ лет, либо просиживатели штанов, либо студенты для строчки в трудовой. Толковые специалисты там не задерживались. Так что близость к спутникам, военной приемке и госаппарату в целом это скорее приговор чем повод для повышения авторитета. > Баги и странное поведение работы программ наблюдалось в итоге. Что-то где-то запустили, после чего-то что-то стало не работать почему-то. Никакой конкретики, которой можно было бы ожидать.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	285. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 18:05
	> недоконца > как не странно > не понятных Чадо, у тебя не "в компеляторе" проблема (и даже не в тех рукожопах, которые так систему сборки умудрились написать, что получили невоспроизводимый результат для, скорее всего, теми же конечностями писаных исподников). А в тройке по русскому для начала, если по-честному.  И натянутой тройке -- по математике. Не кивай на других.  Не обобщай с умным видом того, в чём вообще не соображаешь. Начни с себя. А там и космос вытянем заново, и не только его.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	313. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Ordu (ok), 05-Янв-22, 01:41
	> Может я недоконца обозначил проблему Определённо. > Это было исследование на предмет расспараллеливания кода при компиляции на 100500 процессоров и как это влияет на конечную стабильность работы программ после сборки и запуске на реальном оборудовании. Вот тут как раз было бы очень интересно увидеть ссылку на это исследование. Реально любопытна методология исследования, особенно та часть, которая описывает выборку, на которой проводилось исследование. Но ещё более интересен список идентифицированных причин таких багов, потому как это явно грабли, которые неплохо было бы уметь перешагивать.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	337. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 13:41
	Может это был distcc? Да, там бывают свои приколы
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	249. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от pavlinux (ok), 04-Янв-22, 14:44
	> Если параллелизация на уровне Make, то со стабильностью ниче не будет (как > повлияет на стабильность одновременная компиляция независимых исходников?). LTO, не, не слышал?   Линковка  a+b+c+d, это не тоже самое что (a+b) + (c+d) ... и вообще разное (a+d) + (b+c) > Реальные проблемы при сборке - это то, что сами Makefile-ы написаны отстойно, > т.е. могут отсутствовать правила, указывающие правильную очередность сборки, в результате > чего можно влет получить состояние гонки, Сцк, откуда вы все повыползали??!!! С онлайн курсов чтоль?   Race condition - это борьба за общий ресурс, make - это линейная приблуда. -j n - это тупа n форков со своими линейными списками.   > когда с первой попытки не соберется, а со второй - вполне себе.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	287. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 18:07
	>> Если параллелизация на уровне Make, то со стабильностью ниче не будет (как >> повлияет на стабильность одновременная компиляция независимых исходников?). > LTO, не, не слышал? Ставлю навскидку тыщу рублей, что описанное в #74 было без -flto со товарищи :)
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (53), 04-Янв-22, 19:54
	> Линковка  a+b+c+d, это не тоже самое что (a+b) + (c+d) ... и вообще разное (a+d) + (b+c) Как эт ты их так сгруппировал? Я так не умею, у меня линковщик все файлы разом хочет получить. Причём make ему даже аргументы всегда в одном и том порядке подставляет независимо от -j.
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	312. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (46), 05-Янв-22, 01:36
	Рейс кондишн в мейкфайле - это когда есть фактическое happens-before отношение между множеством исходников X и Y по коду, и эти X и Y собираются в разных makefile-таргетах. И при этом нет явного указания в мейкфайле, что один таргет является зависимостью другого. Господин павлин(-ункс), кто ж с тобой спорит-то, что race conditition - это борьба за общий ресурс. Здесь общий ресурс - каталог build/output, откуда все таргеты используют выхлоп друг друга. Если раньше отработает неявный дочерний таргет и положит результат в build/output, то все ок - неявный родительский таргет обнаружит что надо и успешно соберется. А если не повезет и раньше начнет работу родительский и компилятор не обнаружит чего хотел - сборка свалится.
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	338. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 13:44
	Приведи пример зависимости сборки объектника от другого объектника.
	Ответить | Правка | Наверх | Cообщить модератору

	402. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (402), 07-Янв-22, 16:54
	Это заблуждение часто наблюдается у программеров-прикладников, которые рейсом называют всё, что то работает, то нет. Слово-паразит.
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	67. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Онаним (?), 03-Янв-22, 13:22
	А что там на стабильность-то влияет? Собираются файлы всё равно независимо, между зависимостями сборка притормаживает. Финальный выхлоп делает ld, ему как-то на количество ядер фиолетово.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	63. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Кирилл (??), 03-Янв-22, 13:15
	А известно ли, какая машина у тестирующего? Когда я занимался правками ядра, нам выдавали простенькие атлончики. И инкремент шёл 5 минут. И можно было идти гулять. Торвальдс же, недавно рекомендовал amd 3970x. Как базовую машину. Но тут что-то мощнее.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	43. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Аноним (40), 03-Янв-22, 12:26
	И что вы с ней будете делать.Оплачивать счета за электроэнергию?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	128. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Смузихлёб (?), 03-Янв-22, 16:51
	> j96? дайте мне такую машину В наши дни такие машины – абсолютная норма, особенно если ты серьезный разработчик, а не веб макака. Очнитесь уже со своими core 2 duo и добро пожаловать в этот дивный новый мир.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	180. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (180), 03-Янв-22, 21:23
	Расшарь-ка мне пару сотен своих ядер. Раз у тебя там мир такой новый и дивный.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Иваныч (??), 04-Янв-22, 13:49
	amazon EC2 вам в помощь - не благодарите
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (258), 04-Янв-22, 16:52
	>Очнитесь уже со своими core 2 duo и добро пожаловать в этот дивный новый мир. Ты чо, как так можно? У вас там страшные штеуд МЕ, уефи и другие непонятные аббревиатуры
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	261. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Смузихлёб (?), 04-Янв-22, 16:59
	> Ты чо, как так можно? У вас там страшные штеуд МЕ, уефи > и другие непонятные аббревиатуры Отдельная PCI сетевуха спасёт отца русской демократии.
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Смузихлёб (?), 04-Янв-22, 16:53
	> j96? дайте мне такую машину В наше время пользователь core 2 duo - это человек пожилого возраста или бухгалтер в не прибыльной конторе. Для большинства же пользователей двух\четырёх ядерные системы окончательно умерли в период 2015-2017 годов, оставив лишь нотки ностальгии.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	330. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (330), 05-Янв-22, 12:10
	>j96? дайте мне такую машину 2 шт. Baikal-S
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+10 +/–
Сообщение от Отсутствуют данные в поле Name (?), 03-Янв-22, 11:32
Таненбаум был прав
Ответить | Правка | Наверх | Cообщить модератору

	10. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–10 +/–
	Сообщение от Ananima (?), 03-Янв-22, 11:37
	Всегда был, все это знают. Вот вам голая правда о поделии аутиста Линуса.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Gogi (??), 03-Янв-22, 13:44
	А чё минусуют? Всё правильно сказал. Этот Трольвадс тот ещё баран упёртый! Послушал бы "старших товарищей" - сейчас бы в ядре было 20 файлов, а всё остальное спокойно И НЕЗАВИСИМО жило в отдельных мирах. Короче, баранолинукс достиг стадии, когда понятно, что ишак сдохнет, но пытаются проехать лишние 100 метров.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Rev (?), 03-Янв-22, 13:54
	Похоже. что в Гугле уже это поняли, причём несколько лет назад, и уже серьёзно пилять Фуксию на замену.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+5 +/–
	Сообщение от Аноним (-), 03-Янв-22, 14:16
	Фуксия они полят ради того чтобы иметь свою коммерческую Ось. Архитектура не причём.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (250), 04-Янв-22, 14:46
	> не причём схоронил
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (317), 05-Янв-22, 07:31
	Да обсохраняйся. Symbian и QNX/BBerryOS показывают, что в условиях приближенных к реальной жизни, микроядро почему-то не взлетает. Хотя концепция, конечно, красивая.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Криптоханыга (?), 03-Янв-22, 17:23
	Самое смешное - фактически к этой концепции всё и пришло! На серверах крутятся микроядерные гипервизоры, в которых на правах сервисов живую виртуалки и контейнеры. Запуск и умирание которых не приводит к падению базового гипервизора.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	264. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от keydon (ok), 04-Янв-22, 17:08
	Ждём ядро без фатальных недостатков от Gogi на 20 файлов.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	131. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Смузихлёб (?), 03-Янв-22, 16:54
	Не зря яблоОС пошла по пути микроядерности, являясь де-факто самой надёжной осью. Хотя, конечно, играет фактор того, что и железо и ось пилит одна компания, в отличии от зоопарка ПК железа.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	247. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–4 +/–
	Сообщение от Аноним (247), 04-Янв-22, 14:37
	Там гибрид.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от uis (ok), 05-Янв-22, 14:05
	Еблёс - шматки Mach 3, никакого там микроядра не осталось
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	436. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Заноним (?), 16-Янв-22, 03:19
	Оно и видно что смузихлёб. Всё правильно сказали - нет в огрызкоси никакой микроядерности.
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	140. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (-), 03-Янв-22, 17:12
	Безусловно. Ведь он профессор, а Линус студент. Концептуально MINIX очень крутая ОС. А Linux превращается в Вавилонскую башню.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	165. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (165), 03-Янв-22, 19:24
	Ну и где его minix теперь? Ты им сам-то хотя бы пользуешься?
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	166. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от dflgjldfgjoldigjoildfjg (?), 03-Янв-22, 19:30
	minix everywhere - intel me :D
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 14:05
	Официально Таненбаум негодует
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (168), 03-Янв-22, 21:04
	много где - просто тебе об этом не будут сообщать.
	Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

	260. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (258), 04-Янв-22, 16:57
	"У нас есть такие приборы - но только мы их не покажем" серия 100500-я. Суровое академическое BSD-строение во всей красе.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 04-Янв-22, 19:56
	> "У нас есть такие приборы - но только мы их не покажем" > серия 100500-я. Суровое академическое BSD-строение во всей красе. С разморозкай - для SaaS, в котором сейчас заколачивают миллиарды, что GPLv2/3, что BSD - совершенно без разницы. У Гугеля вон, еще 14 лет назад был стабильный и улучшенный EXT2 и кажись, планировщик, но ...
	Ответить | Правка | Наверх | Cообщить модератору

16. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
Сообщение от Аноним (16), 03-Янв-22, 11:49
Мне непонятно как они вообще всё это мержат? Он год назад делал срез, за этот год ещё куча кода, новых заголовочных файлов и т.п. Очень интересно как они в состоянии с этим совладать?
Ответить | Правка | Наверх | Cообщить модератору

	21. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от А где же каменты (?), 03-Янв-22, 11:58
	git rebase постоянный
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от pashev.me (?), 03-Янв-22, 12:05
	Ща те каргокультисты скажут, что рибэйз - это зло 🤭
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Какаянахренразница (ok), 03-Янв-22, 13:14
	Rebase -- наше фсё. А зло это merge.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от user (??), 03-Янв-22, 13:36
	Костыль для любителей линейной истории.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от А где же каменты (?), 03-Янв-22, 15:13
	Merge комиты выглядят уродливо. Какие у merge стратегии преимущества перед rebase?
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+11 +/–
	Сообщение от Какаянахренразница (ok), 03-Янв-22, 16:21
	Моё дело -- вбросить. А дальше вы уж как-нибудь сами.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (53), 03-Янв-22, 21:02
	Давно ли они стали альтернативой друг другу?
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	181. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от А где же каменты (?), 03-Янв-22, 21:28
	Да, всегда были
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от мое правило (?), 03-Янв-22, 23:34
	С мердж комитами прикольно. Иногда надо покупать парочку пузырей водяры, звать пацанов что бы разобраться как и куда идут эти сраные ветки. С линейной историей поводов с пацанами собратся будет меньше :(
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	314. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от fuggy (ok), 05-Янв-22, 02:47
	Ребейз это переписывание истории, то есть вместо одно коммита создаёт на его основе новый коммит, который не тоже самое. Если автор взглянет на свой коммит после ребейза, он его не узнает. Коммит будет отличатся от того чтобы было задумано, но будет сформирован автоматически, от чего может возникнуть ошибка там где её никто не ждал. А уж о проблеме что это полностью портит работу остальных, кто ответвился до ребейза и говорить не стоит.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	352. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Аноним (46), 05-Янв-22, 14:31
	1) Если конфликты при ребейзе, то они будут и при мердже и всё равно придется аккуратно разбираться, чтобы ничего не потерять. 2) Для ребейза есть один строгий шаблон, когда он уместен - 1 разработчик работает строго в фича-ветке своей задачи и делает ребейз ТОЛЬКО с релизной/мастер веткой, перезаписывая коммиты в своей origin/feature ветке через легальный(!) пушфорс. Адекватные люди никогда не делают ребейз, если в одну ветку коммитят несколько разрабов - оно не для этого флоу было придумано.
	Ответить | Правка | Наверх | Cообщить модератору

25. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
Сообщение от pashev.me (?), 03-Янв-22, 12:04
В Солярке такая же беда.
Ответить | Правка | Наверх | Cообщить модератору

	234. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (234), 04-Янв-22, 13:10
	В случае солярки это проблема вида "цветки на могилке слишком быстро вянут".
	Ответить | Правка | Наверх | Cообщить модератору

29. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–7 +/–
Сообщение от Аноним (40), 03-Янв-22, 12:10
Не факт что расспаралеливание кода на ядрах процессора приносит улучшенную  стабильность бинарника на выходе.Сами разработчики GCC рекомендуют иногда компилировать в один или два потока.Так что новость актуальна.Можно компилить теперь в один поток быстрее.У кого эпики или 100500 ядер профита не получат вообще.
Ответить | Правка | Наверх | Cообщить модератору

	51. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+6 +/–
	Сообщение от Аноним (53), 03-Янв-22, 12:48
	Какая ещё стабильность бинарника, деточка? Иди уроки делай. И запомни, что распараллеливание сборок на конечный ре0зультат не влияет. Но не всегда оправданно, потому что рано или поздно бутылочным горлышком окажется io.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–5 +/–
	Сообщение от Аноним (40), 03-Янв-22, 12:57
	Деточка это вы почитайте доки gcc и gentoo потом пишите.А еще поинтересуйтесь как разрабатывается код под процессоры для орбитальных спутников и космических зондов.Да ракеты забыл извините деточка.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (53), 03-Янв-22, 21:05
	И сейсас ты такой — хопа! — вывалил ссылки на нужные места доки gcc и gentoo и рассказал тру стори, как разрабатывал код для спутников, какие нашёл грабли, и в чём была их причина. Эх, что-то размечтался я…
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (40), 04-Янв-22, 09:39
	Это секретная информация.Государственная тайна.Вам деточка этого никто не раскажет.Так что товарищ майор иди ищи дураков и делай себе карьеру в другом месте а здесь на форуме приличные люди программисты.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Прохожий (??), 04-Янв-22, 11:06
	>нужные места доки gcc и gentoo Это гостайна? :)))
	Ответить | Правка | Наверх | Cообщить модератору

	345. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 14:09
	В нужных местах можно узнать всё, а всё - гостайна, значит и нужные места тоже
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+8 +/–
	Сообщение от Аноним (46), 03-Янв-22, 13:37
	Уважаемый, какая "параллельная" компиляция на GCC? Каждый отдельный unit of compilation собирается в 1 поток (потому что при добавлении параллелизма теряется sequential context и из-за этого теряется возможность многих важных оптимизаций). Там только в 2020 году на Google Summer of Code был хакатоновский проект по добавлению параллелизации в сборку отдельного юнита, который до сих пор в стадии proof-of-concept. Сейчас параллелизация происходит только на уровне Make-файлов, когда независимые рецепты собираются одновременно. Все баги, которые лезут при параллельной сборке, происходят из-за криво написанных Make-файлов или из-за состояний гонки внутри самой утилиты make.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	91. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Кирилл (??), 03-Янв-22, 13:55
	Если нестабильность на уровне сборки - надо заводить багу. Искать повторяемость ошибки. Потом локализовывать место возникновения. И затем исправлять. Исправлять какие ошибки не сложно. Так как можно закрыть ошибку меньше, чем за неделю. Главное не плодить правила сборки. И не искать виновных. Толка чуть. Не Боги горшки лепят. Все ошибаются. И исправить можно.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	106. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (96), 03-Янв-22, 15:13
	Какой умный мальчик. Ящик печенья и банку варенья герою. Проблема глубже, чем воспитала юных хакеров современная система: компилируется - значит работает. Всегда есть сложновоспроизводимые проблемы из-за гонок, отсутствия необходимого железа, реверс-инжиниринга для поддержки проприетарного железа или наличие крикливых индусов с LGBT+ поддержкой. Из-за этого поддержка кода превращается в кривой спаггеттинг, вносятся изменения в зависимости от каждой платформы или вносятся противоречивые правки через дефайны, которые очередным индусом-оптимизатором приводятся к неработающему коду.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (189), 03-Янв-22, 23:10
	Ты пьян, обдолбан или просто шизофреник?
	Ответить | Правка | Наверх | Cообщить модератору

	371. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от нах.. (?), 05-Янв-22, 17:07
	Нет, он просто говорит правду. А такие как ты ее никогда не слышали или не желают слушать. Вас воспитала та самая система.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от макпыф (ok), 03-Янв-22, 17:46
	Что ты несешь? 1. Причем тут вообще расспаралеливание 2. На уровне make это ни как не влияет на сами бинарники
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	265. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:14
	> улучшенную  стабильность бинарника Что Вы несёте?
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	434. "ну он медленнее распадается и гниёт"	+/–
	Сообщение от примерно_36_скотинок (ok), 13-Янв-22, 15:59
	ну он медленнее распадается и гниёт. период полураспада опять же увеличивается.
	Ответить | Правка | Наверх | Cообщить модератору

30. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
Сообщение от Аноним (30), 03-Янв-22, 12:10
Быдлокод на сях - это быдлокод в квадрате. Побочный эффект от того, что заголовочные файлы просто тупо инклудятся друг в друга, так что небольшой с виду код может в итоге оказаться для компилятора просто гигантским. Ну и перекомпиляция одного и того же по 100500 раз. Проблема решена в делфях, где юниты компилятся отдельно. Это делает компиляцию почти мгновенной. Но есть проблема. Перекресные ссылки невозможны. И это немного противоречит логике. Т.к. то, что можно реализовать внутри одного модуля, почему то нельзя реализовать, если просто для красоты разделить программу на два. Приходится танцевать с бубном. Но такая вот специфика. За скорость нужно платить.
Ответить | Правка | Наверх | Cообщить модератору

	36. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Аноним (40), 03-Янв-22, 12:16
	Так ведь Delfi вроде мертв.Не?
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–4 +/–
	Сообщение от Аноним (30), 03-Янв-22, 14:42
	Он мертв не поэтому. А потому, что кто то хочет овердофига бабла за лицензию. А лазарус, как и любая другая слоупочная опенсурцная муть, развивается крайне медленно. По релизу (условно) в год с мелкими исправлениями. Иногда мне кажется, что эти опенсурцеры просто в игрульки играются. Мол у нас есть проектик. Мы с ним играемся. Но у нас по сути нет ни одного человека, который мог бы реализовать что то реально стоящее. А потому мы раз в год прикрутим какой нибудь маленький фикс совместимости с делфи.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от ms is piece of s (?), 03-Янв-22, 18:20
	>> Но у нас по сути нет ни одного человека, который мог бы реализовать что то реально стоящее. Кто тебе мешает стать этим самым человеком?
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:14
	Обычно это лапки...
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (182), 03-Янв-22, 21:47
	Double Commander. Вполне солидный проект.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	273. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от другой Вася2 (?), 04-Янв-22, 17:32
	>> Но есть проблема. Перекресные ссылки невозможны Очень даже возможны. Попробуйте часть ссылок в "interface", а остальные в "implementation"
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

33. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
Сообщение от pashev.me (?), 03-Янв-22, 12:13
Идеальное прикрытие для внесения бэкдоров.
Ответить | Правка | Наверх | Cообщить модератору

	213. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (-), 04-Янв-22, 09:39
	Это русский?
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:15
	Инго-то Мельниченко? Не, куда там. Но мужик грамотный.
	Ответить | Правка | Наверх | Cообщить модератору

38. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+6 +/–
Сообщение от Аноним (38), 03-Янв-22, 12:18
Если примут, то это на 6.0 уже потянет
Ответить | Правка | Наверх | Cообщить модератору

	41. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (40), 03-Янв-22, 12:24
	Примут примут обязательно ждемс с нетерпением.
	Ответить | Правка | Наверх | Cообщить модератору

45. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
Сообщение от kot to (?), 03-Янв-22, 12:31
Про Rust Уже вспомнили ?
Ответить | Правка | Наверх | Cообщить модератору

	70. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (65), 03-Янв-22, 13:26
	вспомнили что не нужен
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Прохожий (??), 04-Янв-22, 10:11
	Разве что таким неосиляторам, вроде тебя.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от Аноним (250), 04-Янв-22, 14:48
	я начинал учить раст, очень его хвалили, но умер от потери крови, вся из глаз вытекла от синтаксиса. пишу с того света
	Ответить | Правка | Наверх | Cообщить модератору

	342. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 14:01
	> я начинал учить раст, очень его хвалили, но умер от потери крови, > вся из глаз вытекла от синтаксиса. пишу с того света Может к окулисту сходишь для начала? Обычно, люди склонны винить всех вокруг в своих бедах, только не себя.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Анонн (?), 03-Янв-22, 13:37
	Зачем о нем вспоминать если это было сделано по-человечески еще в делфях задолго до раста? Хотя у него с модульностью тоже все прекрасно. Вообще сложно представить хоть что-то, где модульность будет хуже чем в си.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	233. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 04-Янв-22, 13:09
	> Зачем о нем вспоминать если это было сделано по-человечески еще в делфях задолго до раста? Delphi не бесплатны. Rust - бесплатен. Хотя бы поэтому. У Rust удобней инфраструктура (ИМХО). Rust поддерживают MS, Google, Mozilla, Huawei. Delphi - только Borland, которая уже далеко не торт.
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (286), 04-Янв-22, 18:07
	>У Rust удобней инфраструктура (ИМХО). Тоже программироуешь браузеры?
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 13:51
	Rust не только для браузеров подходит.
	Ответить | Правка | Наверх | Cообщить модератору

	346. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 14:12
	Что? Зачем?
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

47. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+6 +/–
Сообщение от Аноним (321), 03-Янв-22, 12:36
Проблема в том, что с точки зрения функциональности, стабильности, надёжности, безопасности и скорости работы эти патчи ничего не улучшают. Для пользователей эти патчи ничего не добавляют, но при таком объёме изменений возникновение функциональных регрессий почти неизбежно, а эти регрессии уже могут влиять на качество работы ядра, а не только на удобство его сборки.
Ответить | Правка | Наверх | Cообщить модератору

	49. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (40), 03-Янв-22, 12:41
	Совершенно верно вот и надо будет больше тестов а потом как всегда патчи патчи и еще раз патчи.Энтропия вселенной однако.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от tty0 (?), 03-Янв-22, 12:59
	Как практик, могу сказать, что после повышения времени сборки 3 минут - ошибки начинают возникать просто из-за вынужденной смены контекста при ручной проверке
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+8 +/–
	Сообщение от Аноним (61), 03-Янв-22, 13:08
	Патчи приводят кодовую базу в порядок. Из-за свободы, которую даёт разделяемая сборка в С и С++, разработчикам часто сносит голову, и они начинают включать заголовки не глядя, создавая бардак из перекрестных включений. Что не только существенно замедляет скорость сборки, но ещё затрудняет понимание структуры кода человеком, а также приводит к незаметным ошибкам связанным с порядком обработки препропроцессором объявлений-макросов. В С++ уже приняли modules, которые в перспективе могут улучшить ситуацию. А вот в С остаётся уповать только на разработчиков. Но люди - это всегда слабое звено: они невнимательны, глупы и ленивы.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	82. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Аноним (250), 03-Янв-22, 13:43
	> разработчикам часто сносит голову, и они начинают включать заголовки не глядя, создавая бардак из перекрестных включений. но ты, конечно, не из их числа, зато аналитика у тебя уровня 80
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Аноним (16), 03-Янв-22, 18:03
	Так ты плати за рефакторинг и проблем не будет. Аааа...не хочешь? Ну тогда терпи.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	156. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 03-Янв-22, 18:16
	в линуксе заголовочные файлы адский ад, тут включи дефайны gnu, там bsd и смотри не перепутай, соберётся, но с ошибками в процессе работы.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	224. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Прохожий (??), 04-Янв-22, 11:11
	Линукс написан на Си. Там НЕ БУДЕТ Си++. Поэтому появившаяся в этом языке модульность ничего не изменит. Шанс есть только у  Rust пока что.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	85. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (46), 03-Янв-22, 13:48
	Как бэкенд разработчик в ентерпрайз проекте на 3 млн строк кода, выражу мнение, что без чисто технического рефакторинга, который ничего продуктового не добавляет, а только уменьшает техдолг тяп-ляпных архитектурных решений, проект со временем становится невозможно сопровождать. В каждой большой компании есть правило, что N процентов спринта команды отводится на ликвидацию имеющегося техдолга.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	268. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:22
	> Для пользователей эти патчи ничего не добавляют Если маме освободить больше времени (скажем, купив стиралку или посудомойку) -- может статься, ей получится уделить больше времени сынишке.  Как-то так и тут. Причём со сборками теми же есть эффект потери/сохранения контекста: пока что-то происходит достаточно долго (минутку или пять -- всяко дольше тех секунд двадцати, которые ты лично его согласен обождать без переключения на другое), протерять собранный в голове контекст или его нюансы несколько проще, чем когда make\n -- размял плечи, шею, посмотрел вдаль в окошко, о -- а вот и результат готов. С другой стороны, если прерывания по делу идут слишком часто, тоже бывает нехорошо (в сторону выжатого лимона и в клиническом случае -- выгорания).  В этом плане опять вспоминаются http://lib.ru/MEMUARY/ERSHOW_W/zapiski_ezdowogo_psa.txt насчёт различия полётов на Ил-18 и Ту-154 с точки зрения количества рейсов в сутки...
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	301. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от jezhik (?), 04-Янв-22, 19:51
	Однако в реальности после обретения стиралки эта мама будет либо больше залипать в сериалы, либо сможет лишние пару раз вымыть полы или протереть пыль. Так люди устроены.
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 14:13
	Эти регрессии будут способствовать на порядки большей прогрессии
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

64. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–5 +/–
Сообщение от Аноним (64), 03-Янв-22, 13:16
"с 15.5 до 27.7 сборок в час" ниочом же, мой монитор 144fps. Я хочу 1 сборку на каждый фрейм. Играть в линукс на ~30fps это слайдшоу. Жду новые райзены TR с DDR5.
Ответить | Правка | Наверх | Cообщить модератору

	87. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Анон_ли (?), 03-Янв-22, 13:52
	Путаешь частоту обновлений с частотой кадров.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:23
	Он часы с секундами путает (и fps с bph), если что... но типа смешно.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (122), 03-Янв-22, 16:44
	Забуферизируй каждую сборку и выплюни её в 144 кадра, когда всё случится. А чё, сейчас пинг с карты в 20 мс — это норма, народу нравится.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	150. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от mikhailnov (ok), 03-Янв-22, 17:58
	А вы запустите сборку ядра с высокой говорливостью, будет не успевать выводить в терминал, при должной оптимизации, возможно, упретесь в 144 FPS, были же новости про GPU-ускорение для отрисовки текста в терминалах, над ними смеялись, а вот оно и пригодится.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

71. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
Сообщение от th3m3 (ok), 03-Янв-22, 13:28
Чую нас ждёт год оптимизаций. Будет круто, если эти патчи примут в этом году. К концу года Python ускорят. Явно будет ещё что-то.
Ответить | Правка | Наверх | Cообщить модератору

	80. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (65), 03-Янв-22, 13:38
	Вот бы ещё пайтоновцы немного на другие, особенно мобильные, архитектуры хоть иногда смотрели и собирали либы и под них, цены бы им не было
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (53), 03-Янв-22, 21:11
	> К концу года Python ускорят. Скажи ещё, GIL выпилят.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	188. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (17), 03-Янв-22, 23:09
	Не выпилят, но сделают возможность в одном процессе спаунить subinterpreters. Это можно и сейчас уже в 3.10, но сейчас подинтерпретаторы шарят GIL. А в 3.11 обещают сделать, чтобы каждый subinterpreter имел свой собственный GIL. Если это сделают - то ты сможешь делать в одном процессе сколько угодно независимых объектов-интерпретаторов, не шарящих общий GIL, глобальный для процесса. А значит ты сможешь в мультитрединг с закэнселленым GIL.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от JavaScript (??), 03-Янв-22, 23:49
	Питоновцы изобретают Веб-Воркеры.
	Ответить | Правка | Наверх | Cообщить модератору

	397. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (397), 06-Янв-22, 20:52
	Питоновцы могут запускать ивент лупы программно, прикинь! Надеюсь с пальмы не упал?
	Ответить | Правка | Наверх | Cообщить модератору

79. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–6 +/–
Сообщение от Gogi (??), 03-Янв-22, 13:38
...и вся эта помойка развивалась под неусыпным наблюдением главного Пингвинукса-трольвадса... он что, вообще ни в зуб ногой в Си? Неужели городить помойку годами не вызывало у него хотя бы инженерного чувства брезгливости? Тоже мне, "революционер"!
Ответить | Правка | Наверх | Cообщить модератору

	97. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 03-Янв-22, 14:21
	Гоги вы чьих будете? За Паскаль топите.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (122), 03-Янв-22, 16:48
	Вы бы патчи ему кидали, а не гнали на человека лишний раз. Он написал ядро и дожил до 2022, всё ещё находясь в статусе его мейнтейнера. Пора ли деду на пенсию или нет — вопрос субъективный, но факт в том, что содержать такую большую помойку из кода, который работает и работает великолепно в 99% случаев — это как минимум достойно уважения.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

81. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
Сообщение от Rev (?), 03-Янв-22, 13:42
> на стадии постпрепроцессинга Что за дебильный язык, в котором нужна фаза пост-пре-процессинга???
Ответить | Правка | Наверх | Cообщить модератору

	92. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Gogi (??), 03-Янв-22, 13:55
	гbI-гbI :) Добро пожаловать в 70-ые! Время _килобайтной_ памяти и самых маразматических решений в ИТ! Каждый язык развивался в меру шизанутости авторов (привет, ЛИСП!) и потому ТОГДА это никого не удивляло и не вызывало инженерных споров. Сегодня Си - самое маразматичное, что можно использовать для разработки.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от Аноним (103), 03-Янв-22, 14:52
	Сегодня это любой язык, Сишечка просто не прячет этапы и позволяет исполнять их раздельно. Маразматично выбирать язык по принципу лишь бы хайповым был, на сегодня у си нет альтернатив по качеству и эффективности батареек и нет никаких предпосылок к изменению ситуации. Я даже не вижу что через 30 лет какой-нибудь язык мог бы сравняться с сишечкой, может быть плюсы лет через 100 догонят.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–4 +/–
	Сообщение от Анонн (?), 03-Янв-22, 15:23
	Сегодня у си нет альтернатив по количеству рукожопства с памятью, выходов за границы массива и переполнений буфера (и тысяч cve как результат). С ним может поспорить только с++ в проектах, для погромистов которых это всего лишь "си с классами" и они не используют правильное RAII ради мнимой производительности, а таких еще очень много.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (103), 03-Янв-22, 15:37
	Хотя бы быстро компилируется и работает. Современные инструменты позволяют избегать большинства ошибок. Статистически все эти переполнения случаются в 1 из миллионов случаев применения адресной арифметики, что не так и плохо. Критические ошибки с перепутанными знаком, порядком аргументов, или прочее подобное случаются куда чаще и в любом языке, и от них нет никакой защиты.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Анонн (?), 03-Янв-22, 18:13
	От перепутанного знака могут помочь юнит-тесты, от неправильной бизнес-логики - интеграционные. А от выхода за границы массива при неудачных входных параметрах - даже фаззи-тестинг помогает в единичных случаях. Так что мимо.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (103), 03-Янв-22, 18:47
	Почему тогда не помогают?
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (258), 04-Янв-22, 17:06
	Потому, что теоретизировать - это вам не код писать.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от YetAnotherOnanym (ok), 03-Янв-22, 16:22
	> нет альтернатив по количеству рукожопства с памятью, выходов за границы массива и переполнений буфера У тех, кто прогуливал в школе арифметику и не умеет складывать-вычитать целые числа.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	143. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Анонн (?), 03-Янв-22, 17:21
	Не, ну зачем вы так про разрабов ядра linux, openssl, xorg, firefox и сотен других. Они вполне неплохие люди и программеры, не нужно их так обижать. Но раз в год они себе стреляют в ногу, а иногда оно ее отрывает по самую Ж, причем не только им, но и миллионам благодарных юзеров.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (103), 03-Янв-22, 18:52
	Дело тут скорее в сложности продуктов. Да и на "безопасных" языках что-то не спешат пилить альтернативы (они ещё и конкурентоспособными должны быть при этом). Всех достижений "мы переписали очередной приветмир на додиез".
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Прохожий (??), 04-Янв-22, 10:28
	Пилят потихоньку. Просто достаточной массы разработчиков не набралось пока.
	Ответить | Правка | Наверх | Cообщить модератору

	319. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (234), 05-Янв-22, 07:47
	И не наберётся. То ж не формы на венде клепать, тут думать надо.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 14:17
	Судя по опросам StackOverflow - процесс пошёл. А ты и дальше можешь продолжать "думать", что спрятав голову в песок аки страус, избежишь прогресса.
	Ответить | Правка | Наверх | Cообщить модератору

	381. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (381), 06-Янв-22, 02:19
	> ...Да и на "безопасных" языках что-то не спешат пилить альтернативы ... Тут все не так просто и с Си, и с "безопасными" языками... Ведь процессор ну абсолютно ничего не знает о массивах, строках, буферах и других структурах (в том числе и указателях), которыми оперируют языки высокого уровня. у процессора есть адреса ячеек памяти в регистрах - это все, что он может и "понимает". Да, на Си можно написать код, который будет вести себя подобно "безопасным" языкам, но, как и в этих "безопасных" языках это будет не "бесплатно" - требует определенного процессорного времени на проверки выхода за пределы высокоуровневых структур данных. Магии НЕ СУЩЕСТВУЕТ в нашем мире! "Безопасные" языки используют точно такие же низкоуровневые команды процессора, что и Си, и даже Асм, которые работают с адресами ячеек памяти или с регистрами (но в них данные нужно загрузить из тех же ячеек памяти с их адресами или выгрузить в нужные ячейки памяти по адресам) - других команд у процессора просто нету. Просто на каждый чих эти языки тем или другим способом автоматически добавляют пачку проверок в runtime - ведь на этапе компиляции не все адреса извесны. Никто не запрещает аналогично поступать на Си и на Асме. НО! При этом растет "служебная" нагрузка на процессор (на проверки всех границ и условий) - программа работает медленнее. Да, я знаю, что мне сейчас тут набросают примеров программ на Си и на $SAFE_LANG, когда на Си медленнее - но тут необходимо детально разбирать алгоритмы и код. При использовании одинаковых алгоритмов и оптимального их кодирования на Си будет быстрее - за счет отсутствия принудительных проверок на каждый чих. А обратный результат вероятнее всего говорит либо о разных алгоритмах (для программы на Си менее оптимизированный) либо о неоптимальном кодировании алгоритма на Си. Да, я знаю про Паскаль, Модулу и Оберон - но там та же петрушка, иначе это никак реализовать на современных архитектурах процессоров невозможно. Даже Java-процессоры не оперируют высокоуровневыми структурами данных.
	Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

	388. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Янв-22, 16:41
	> Магии НЕ СУЩЕСТВУЕТ в нашем мире! Дай я пожму твою руку!
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:26
	> У тех, кто прогуливал в школе арифметику и не умеет складывать-вычитать целые числа. Как хорошо, что в России таких негров можно называть неграми.
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	359. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 15:07
	У вас логическая ошибка в высказывании (безотносительно к расистской сути такового): не все негры безграмотны, и не все безграмотные - негры. Причём здесь Россия, кстати? В ней негры живут, что ли?
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Олег (??), 03-Янв-22, 22:55
	Согласимся. По факту это так. Заменить Си нечем :-(. Какой бы он ни был, остальное прочащее на егг замену ещё хуже.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	217. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Прохожий (??), 04-Янв-22, 10:25
	Rust. Вполне адекватная замена.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (234), 05-Янв-22, 07:46
	В "замене" двусвязный список без unsafe уже осилили, или как обычно "не работает - не нужно"? Платформы, отличные от попсового x86 осилили, или как обычно? Сборку стандартной библиотеки без gc осилили или как обычно?
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (-), 05-Янв-22, 12:57
	> Сборку стандартной библиотеки без gc осилили или как обычно? Опеннетовске Воены Антирастового Сопротивления непутание методичек осилили или как обычно?
	Ответить | Правка | Наверх | Cообщить модератору

	382. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (234), 06-Янв-22, 06:36
	Когда крыть нечем, но что-то выcpать надо.
	Ответить | Правка | Наверх | Cообщить модератору

	386. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 06-Янв-22, 13:28
	>>> Tier1 ... aarch64-unknown-linux-gnu > Платформы, отличные от попсового x86 ... >>> Rust does not use a garbage collector > Сборку стандартной библиотеки без gc > gc ... > Когда крыть нечем, но что-то выcpать надо. А ты самокритичный! Осознание - первый шаг к чему-то там, так держать! (На самом деле, мотивация твоих высеров разве что психологам интересна)
	Ответить | Правка | Наверх | Cообщить модератору

	350. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 14:23
	Добавят векторизацию на уровне языка, и ещё 100 лет будет не догнать
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	270. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:25
	> Каждый язык развивался в меру шизанутости авторов (привет, ЛИСП!) Знаете, вот так взять и одной фразой расписаться в своей полной профнепригодности не каждый сумеет. hint: sexp
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	110. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Анонн (?), 03-Янв-22, 15:36
	Си это просто пхп своего времени. Даже хуже, у пхп вначале была эталонная реализация, а относительно нормальные альтернативы начали появляться с версии 5+. У си куча диалектов была с момента создания, куча несовместимых компиляторов, расширений. Никто не думал об архитектуре, главное быстрее портировать юникс на очередной комп. Х*як-х*як и в прод. Первый стандарт появился только лет через 15 после создания языка, и то - они просто записали что уже было по факту. Плюс наяривание на обратную совместимость, из-за которого невозможно выкинуть всю каку, которая накопилась за эти 50 лет. Поэтому и существует такая шизофазия как "постпрепроцессинг"
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	351. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от uis (ok), 05-Янв-22, 14:30
	> У си куча диалектов была с момента создания, куча несовместимых компиляторов, расширений. > Никто не думал об архитектуре, главное быстрее портировать юникс на очередной комп. MSVC видимо тоже юникс собирает. А остальные компиляторы, как ни странно, все поддерживают расширения из gcc. > Плюс наяривание на обратную совместимость, из-за которого невозможно выкинуть всю каку, > которая накопилась за эти 50 лет. Обратную совместимость винды, на которой ты сидишь, обратную совместимость x86 со своим предком из 70-х.
	Ответить | Правка | Наверх | Cообщить модератору

88. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–5 +/–
Сообщение от Gogi (??), 03-Янв-22, 13:53
Что приятно, в Линуксе таки находятся адекватные люди! Сначала переделали файловый бардак и сделали Gobo-linux. Потом (когда до остальных слоупоков дойдёт) это станет мэйнстримом. Затем заголовочники поправят, пофиксив БАРДАК, который Линус разводил десятилетиями. Ну а потом уж дозреют и до перехода на Ди! Но это будет уже при наших внуках.
Ответить | Правка | Наверх | Cообщить модератору

	98. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (-), 03-Янв-22, 14:24
	>переделали файловый бардак и сделали Gobo-linux Как в Виндовсе? >Ну а потом уж дозреют и до перехода на Ди! Но это будет уже при наших внуках. Гоги топит за язык Ди.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (122), 03-Янв-22, 16:52
	Предлагаю Гоги сделать главным мейнтейнером языка Ди (хотя почему Гоги не предложит написать линукс на Porth или другом, например своём самопальном языке — не понятно). Предлагаю проект назвать соответствующе: "Дикс". А что, звучит!
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Аноним (103), 03-Янв-22, 14:57
	За 15 лет не написано ничего известного, у раста куда больше шансов получить распространённость (not to mention раст, в отличие от д, не завязан на рантайм с гц). ПС. гоболинукс -- помойка.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	206. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (205), 04-Янв-22, 06:00
	Шансы равны и равны 0 Обе поделки поделаны чтоб быть и не несут никаких новых концепций Маркентинговое оно
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (103), 04-Янв-22, 07:24
	Сахарок приятный в принципе.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Прохожий (??), 04-Янв-22, 10:37
	>Обе поделки поделаны чтоб быть Не чтобы быть, а чтобы избавиться от тех годами копимых "наработок" на Си, Си ++. Вот один попытался расчистить эти авгиевы конюшни, и пока непонятно, к чему это может привести. А можно было сразу на нормальном языке с нормальной инфраструктурой писать, и вот этого вот труда Сизифа избежать. Но разве ж это можно луддитам объяснить...
	Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

	222. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (103), 04-Янв-22, 11:02
	>на нормальном языке с нормальной инфраструктурой На го нельзя писать системный софт. Можно, если очень хочется, но нельзя. О многих вещах можно сразу забыть.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 04-Янв-22, 13:18
	Думаю, предыдущий высказывающийся имел ввиду Rust, а не Go.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (103), 04-Янв-22, 13:44
	Но ведь то, что он сказал, явно не про руст с его нпм. И в его нпм нет ничего примечательного. А в самом языке нет ничего инновационного или уникального, всё выглядит как костыли для жс-обезьян. Нет готовых батареек, наконец, а те, что есть, работают ощутимо хуже плюсов.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:33
	> руст с его нпм Чего?
	Ответить | Правка | Наверх | Cообщить модератору

	353. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 05-Янв-22, 14:35
	Ржавая версия NPM. Как pip в питоне.
	Ответить | Правка | Наверх | Cообщить модератору

	356. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 14:49
	cargo в Rust куда как функциональней, чем pip в Python.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 14:47
	У Rust нет NPM. Ты его с чем-то другим попутал. В самом языке есть: - строгая типизация  (в C такого нет); - умные указатели (в C такого нет); - контроль висячих ссылок (в C такого нет); - контроль выхода за пределы границ массивов (в C такого нет); - родные макросы (часть языка, в C такого нет); - модульность (в C такого нет, в C++ появилась недавно, но пока только на уровне стандарта без должной поддержки со стороны компиляторов (как утверждают другие участники форума)); - относительная простота освоения (по сравнению с C++); - оптимальный по производительности код на выходе компилятора (такой же быстрый и небольшой по размеру, как у C). При этом в Rust нет: - ситуаций UB, как в C++ (сплошь и рядом); - GC (как в Go); - объектно-ориентированного программирования, вместо него используется куда лучший с точки зрения лёгкости чтения и последующего сопровождения кода принцип композиции (изучение многоуровневой иерархии объектов в ООП да ещё с множественным наследованием - то ещё "удовольствие"). Плюс инфраструктура в виде стандартных crates.io, cargo, форматтера кода, линтера.
	Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

	363. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (103), 05-Янв-22, 15:47
	В первом предложении ты утверждаешь, что нет нпм, потом льёшь список воды, и завершаешь тем, что он самый хороший, потому что у него есть нпм.  Что-то тут не так.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 15:59
	У Rust нет NPM. Или ты централизованную систему пакетов имел ввиду? Если да, то впредь выражайся яснее, если хочешь, чтобы тебя понимали. > он самый хороший, потому что Он самый хороший потому что - перечитай список ещё раз, почему именно, если с первого раза не дошло. Хотя разжую, пожалуй. Централизованное хранилище пакетов ОДНО ИЗ МНОГИХ преимуществ, а не ЕДИНСТВЕННОЕ. > Что-то тут не так. У тебя проблемы с логическим мышлением. Вот что.
	Ответить | Правка | Наверх | Cообщить модератору

	367. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (103), 05-Янв-22, 16:24
	Не систему пакетов, а доверие вендору и к тому, что в гнилой помойке нет и не будет малвари. Это один из основных недостатков. Дальше не читал, уж извини, ничего полезного ты сообщить не способен.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 16:35
	> Дальше не читал Ясно, чукча не читатель. :) > Это один из основных недостатков. И снова проблемы с логикой. Если ты находишь код (библиотеку) на каком-то стороннем сайте (вместо централизованного хранилища), у тебя точно так же нет никакой гарантии, что там не будет мэлвари, как и в случае с централизованным хранилищем. Но тебе, кроме такого отсутствия гарантии, приходится ещё шариться по Инету, тратя на поиски дополнительное время.
	Ответить | Правка | Наверх | Cообщить модератору

	370. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (103), 05-Янв-22, 17:03
	В серьёзном бизнесе не доверяют никаким хранилищам (если только поставщик мамой не поклялся и не отвечает деньгами, да) и проверяют все зависимости прежде, чем привязаться к верифицированному коммиту в системе контроля версий. Для всех используемых пакетов. А на доверии, это всё уровень нмп-помойки и её обезьян, экономящих время, и то, что её активно навязывают (карго), никак не может быть достоинством.
	Ответить | Правка | Наверх | Cообщить модератору

	385. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 06-Янв-22, 13:21
	> В серьёзном бизнесе не доверяют никаким хранилищам Не доверяем - не пользуемся. Или кто-то заставляет? Вроде, простое решение, а поди ж ты, так долго разжёвывать надо. > что её активно навязывают (карго) Cargo - это не только загружатель пакетов извне. Это и система сборки, универсальная, стандартная, фичастая, ничем не уступающая, а местами превосходящаяя то, что есть в C, C++. Не нравится cargo - напишите свою, никто не запрещает. Не нравится crates.io - закройте к нему доступ.
	Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

	424. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 11-Янв-22, 17:02
	> Cargo - это не только загружатель пакетов извне. Это и система сборки, > универсальная, стандартная, фичастая Я вижу очередной npm, оно тоже "не просто загружатель, но и система сборки" и тоже "стандартное".
	Ответить | Правка | К родителю #385 | Наверх | Cообщить модератору

	429. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 11-Янв-22, 23:04
	>> Cargo - это не только загружатель пакетов извне. Это и система сборки, >> универсальная, стандартная, фичастая > Я вижу очередной npm, оно тоже "не просто загружатель, но и система > сборки" и тоже "стандартное". Куда-то не туда ты смотришь. npm - это менеджер пакетов - не совсем то же самое, что система сборки. Но допустим, что ты прав. Где такое же в стандартной поставке есть у C++ или C?
	Ответить | Правка | К родителю #424 | Наверх | Cообщить модератору

	423. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от uis (ok), 11-Янв-22, 16:53
	> При этом в Rust нет: > - ситуаций UB, как в C++ (сплошь и рядом); Читаю: > - прибит гвоздями к x86 > - объектно-ориентированного программирования Си, Ада
	Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

	430. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 11-Янв-22, 23:15
	>> При этом в Rust нет: >> - ситуаций UB, как в C++ (сплошь и рядом); > Читаю: Не тем местом читаешь. >> - прибит гвоздями к x86 И к ARM, и к MIPS, и к RISC-V, и к SPARC. Подробности: https://doc.rust-lang.org/nightly/rustc/platform-support.html Причём везде один и тот же диалект языка, а не как у Си того же - каждый компилятор живёт своей жизнью. >> - объектно-ориентированного программирования > Си, Ада У Раста нет объектно-ориентированного программирования, зато есть функциональное и композиционное. Про Ада ничего не знаю. На Си это, скорей всего, можно сэмулировать, но будет куча лишнего кода. Так что мимо кассы.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (203), 04-Янв-22, 02:01
	Gobo linux даже не смогли pendrive install запилить,
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	272. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:31
	> Сначала переделали файловый бардак и сделали Gobo-linux. [...] > Но это будет уже при наших внуках. Какие ваши внуки, трансгендерно-восхищённые "постчеловеки"?! // нет, это прям какие-то кульбиты высшего пилотажа в самовляпывании в антиориентиры PS: технарям, а также сомневающимся, напомню статью Витуса Вагнера примерно двадцатилетней давности, которая за прошедшее время стала только актуальней, как по мне (и теперь выглядит сказочно "неполиткорректной" на фоне того, во что ударными темпами скотился и продолжает скатываться коллективный запад): http://wagner.pp.ru/~vitus/articles/user-friendly.html
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	305. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (124), 04-Янв-22, 20:51
	Статья примерно из той же оперы что и разговоры малочисленных и нищих совковых автовладельцев о превосходстве "механики" над "автоматом".
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (328), 05-Янв-22, 12:00
	Ремонтопригодность? Не, для поколения айфонов и тиктоков это слишком сложная концепция. Лучше заменим всё целиком, а то пепельница переполнилась.
	Ответить | Правка | Наверх | Cообщить модератору

	329. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (124), 05-Янв-22, 12:06
	Так ведь и автоматы вполне себе ремонтируют, не?
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 15:05
	Как приведенная статья противоречит (опровергает) то, что сделано создателями GoboLinux? Автор статьи, кстати, абсолютно прав: программа должна быть рабом у человека. Сказали - сделала. GoboLinux организацию файловых систем приближает как раз к такому идеалу - человеку нет нужды задумываться (как в других дистрах) о том, где он может найти те или иные бинарники (и/или другие файлы): они всегда будут находиться в одной и той же стандартной структуре папок. Что же в этом плохого, кроме того, что многие админы (и другие пользователи) уже успели привыкнуть (то есть, по сути прогнуться под создателей дистров) к прежней непрозрачной структуре?
	Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

100. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
Сообщение от Аноним (100), 03-Янв-22, 14:39
Следующим шагом будет обфускация заголовочных файлов для экономии места и очередного ускорения
Ответить | Правка | Наверх | Cообщить модератору

	130. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (122), 03-Янв-22, 16:54
	Так це наоборот, деобфускация. Вместо заголовков-всё-в-одном, a.k.a. просто-добавь-заголовок, будут самодостаточные заголовочные файлы без дичайших вложений.
	Ответить | Правка | Наверх | Cообщить модератору

105. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
Сообщение от Аноним (105), 03-Янв-22, 14:59
Вот щас придёт линус в lkml и покажет всем свой финский палец!
Ответить | Правка | Наверх | Cообщить модератору

	202. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от john_erohin (?), 04-Янв-22, 01:48
	шведский.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Брат Анон (ok), 04-Янв-22, 09:20
	Всё-таки финский. Его отец был финном.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Аноним (225), 04-Янв-22, 11:41
	а мама таки да?
	Ответить | Правка | Наверх | Cообщить модератору

	421. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (421), 10-Янв-22, 11:21
	Шведом. Хоть и гражданином независимой Финляндии.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

112. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
Сообщение от Аноним (168), 03-Янв-22, 15:48
а есть такие же патчи, только что бы сам комп на столько же быстрее работал?
Ответить | Правка | Наверх | Cообщить модератору

	275. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:40
	"Сам комп" не умеет, а так вот небольшой комментарий к нашумевшему недавно тестированию сбером эльбрусов (как водится, неназванный учёный изнасиловал журналиста cnews, а дальше понеслось). Если кто обратил внимание на _три_ столбика на графике SPEC CPU -- поставщиками x86-железа заявляются циферки примерно вдвое больше, чем получается намерить при использовании тех компиляторов и их версий, что в проде у того же Сбера.  В некотором смысле было занятно услышать объяснение человека из Intel -- мол, так надо же взять вот эту версию и там к ней ключики указаны... (и такие люди будут ставить на вид МЦСТ их шалости вроде "будем сравнивать производительность, приведённую к частоте") Короче, если вдруг кому кажется, что у вас в ЦОДы закупается слишком много железа за СЛИШКОМ много бабла -- попробуйте прогнать на нём тесты и сравнить с эталонными результатами.  Возможно, из уже имеющегося можно выжать ещё в пару разиков больше, если дать денег не чужим продаванам, а своим специалистам.  Да, SPEC просто так не возьмёшь и не прогонишь, но тот же линпак можно и попробовать: с production toolchain/options и с "олимпиадными". PS: а так-то самому интересно, куда и чьей рукою из технических выводов пропал пункт 3 -- про ограниченную, но уже применимость серийных эльбрусов к поставленным в том тестировании задачам.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Аноним (124), 04-Янв-22, 18:53
	Почему-то любое упоминание Эльбрусов наводит меня на воспоминания об одной статье в журнале "За рулём", советских ещё лет, то ли про ГАЗ-14, то ли про ЗИЛ-117, уже не помню... В той статье авторы всячески расписывали этот автомобиль, отмечая продуманную конструкцию, удобство салона и прочие бесспорно имевшие место достоинства данного аппарата. Вот только финал статьи был беспощадно обескураживающим: этот автомобиль создавался в качестве конкурента таким автомобилям как Роллс-Ройс и Кадиллак, предназназначается он для партийного руководства, а главной целью его создания является выполнение представительских функций для поднятия престижа страны; обычные граждане этот автомобиль купить не смогут.
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от iZEN (ok), 04-Янв-22, 19:38
	Эльбрус никому не нужен. Это — тупиковая ветвь развития микропроцессоров, поддержанная только деньгами. Желания использовать это убожество никогда ни у кого не возникало.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Аноним (258), 04-Янв-22, 19:47
	Отучаемся говорить за всех (с). Я бы купил себе (незадорого), так не продают же.
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (124), 04-Янв-22, 23:47
	Не переживай, после того как чуть ли не половина тамошних пламенных борцов за "русский процессор" перешли в Yadro, стоило только помахать у них перед носом хрустящей бумажкой, скоро и продавать будет нечего.
	Ответить | Правка | Наверх | Cообщить модератору

	332. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от john_erohin (?), 05-Янв-22, 12:37
	> Я бы купил себе (незадорого), так не продают же. удваиваю. если патриотизм генерирует убытки для своего кошелька, то пошел в опу такой патриотизм.
	Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

	298. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (258), 04-Янв-22, 19:45
	>PS: а так-то самому интересно, куда и чьей рукою из технических выводов пропал пункт 3 -- про ограниченную, но уже применимость серийных эльбрусов к поставленным в том тестировании задачам. В перепечатках новости было, я видел. Но там везде в комменты бодро набигала публика с обычным нытьём про распилы, и "лучше бы", так что в целом этот нюанс остался незамеченным.
	Ответить | Правка | К родителю #275 | Наверх | Cообщить модератору

	354. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от uis (ok), 05-Янв-22, 14:39
	Если бы не закрытость эльбрусов...
	Ответить | Правка | К родителю #275 | Наверх | Cообщить модератору

	360. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (124), 05-Янв-22, 15:24
	Увы, это характерная черта русского человека - много философствовать о человеческой природе, о добре и зле и прочих высоких материях, но в реальной жизни палец о палец не ударить, чтобы сделать для людей что-то хорошее. МЦСТ даже утопая не протянет руки сообществу. Обратите внимание насколько это контрастирует с США, которые при всех своих недостатках подарили миру множество интересных проектов, многие из которых также были закрытыми, а то и вовсе засекреченными...
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от pofigist (?), 05-Янв-22, 15:41
	Если бы не убогость архитектуры... DSP-переросток.
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	417. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от . (?), 09-Янв-22, 10:32
	Они считают это - достижением. Опыт itanium ничему не научил. При том что в нем гораздо меньше было свалено на компилятор (но даже и этого интел нешмог на все интеловские и хулетовы деньги)
	Ответить | Правка | Наверх | Cообщить модератору

	420. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от pofigist (?), 09-Янв-22, 22:56
	> Они считают это - достижением. Опыт itanium ничему не научил. При том > что в нем гораздо меньше было свалено на компилятор (но даже > и этого интел нешмог на все интеловские и хулетовы деньги) И ладно бы только итаниум... Эта архитектура была модной лет 25 назад, но в результате - ее все закопали, не только интел. Я если смутно понимаю как этот монстрик будет оптимизироваться под выполнение в СВМ... Куда пойдет вся его оптимизация в момент переключения контента исполнения?
	Ответить | Правка | Наверх | Cообщить модератору

	418. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от . (?), 09-Янв-22, 10:38
	> мол, так надо же взять вот эту версию и там к ней ключики указаны. и, почему же это не сделано? Если тебя интересует, конечно же, пиковая производительность, а не что-то еще, например - удобство разработки и сопровождения, "а производительности нам просто хватает" (но тут пиломатериалы опять в пролете). А у МЦСТ НЕТ никакой другой более быстрой версии и волшебных ключиков, краденый код gcc как-то к тому не располагает. Только "приведенный к частоте" FUD и остается.
	Ответить | Правка | К родителю #275 | Наверх | Cообщить модератору

	419. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от n00by (ok), 09-Янв-22, 12:17
	Я не понял смысл наброса, разве GCC украли EDG фронтенд?
	Ответить | Правка | Наверх | Cообщить модератору

115. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
Сообщение от Аноним (115), 03-Янв-22, 15:53
Будем теперь ядро на 486 собирать за ночь
Ответить | Правка | Наверх | Cообщить модератору

116. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–7 +/–
Сообщение от Не будь васяном (?), 03-Янв-22, 15:56
Это ж какая сейчас скорость сборки тормозная если её можно "оптимизировать" на 50-80% 🤣 Мир Линукса как он есть. Без розавых очков.
Ответить | Правка | Наверх | Cообщить модератору

	134. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (122), 03-Янв-22, 16:59
	На стриме у одного человека видел, насколько тормозной на самом деле nasm (это ассемблер, если чё, т.е. даже не в Си дело) и какие жирные бинарники он выдаёт по сравнению с fasm (у которого нету документации, но всё таки). Скорость достаточно небольшого проекта с 7 секунд (включая компилятор его собственного языка) и мегабайта статического бинарника упала до 2 секунд и килобайта статического бинарника. Может стоит ещё и инструментарий чекнуть, не только код линукса.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+3 +/–
	Сообщение от Аноним (-), 03-Янв-22, 17:21
	> и какие жирные бинарники он выдаёт по сравнению с fasm (у которого нету документации, но всё таки). *рукалицо* Жир бинарника в асме - иключительно вопрос прямизны рук (или желания заморочиться) асмщика. Что касается документации FASM - все с ней нормально https://flatassembler.net/docs.php (причем еще 12 лет назад было - я как раз переписал проектик на пару тыщ строк с MASM на FASM) Но да, оно в виде текста, а не видосика на ютубе.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от макпыф (ok), 03-Янв-22, 17:37
	> nasm ядром используется обычный асемблер из бинутилсов
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

118. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
Сообщение от Линус (?), 03-Янв-22, 16:05
> Что приятно, в Линуксе таки находятся адекватные люди! та не! этот чел просто захотел славы.
Ответить | Правка | Наверх | Cообщить модератору

127. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
Сообщение от YetAnotherOnanym (ok), 03-Янв-22, 16:51
Вот это новогодний подарок! Кто-то начал разгребать эти авгиевы конюшни! Респектище!
Ответить | Правка | Наверх | Cообщить модератору

	138. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+4 +/–
	Сообщение от Смузихлёб (?), 03-Янв-22, 17:06
	По хорошему нужно раз в несколько лет переписывать всё с нуля с оглядкой на актуальное железо, а не тянуть гору костылей, прослоек и надстроек.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Аноним (147), 03-Янв-22, 17:40
	Ниче что у Линукса чаще чем всегда проблемы с новыми железками?)
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (103), 03-Янв-22, 17:58
	При чём тут линукс? Это обязанность производителя поддерживать железо. Всегда поддержку пилят разрабы на зарплате. Просто с линуксом у анонима есть опция поправить что-то самому, а с вендой через пару лет после покупки всё железо отправляется на помойку. Если оно вообще будет работать, например, усб звуковухи с амдшными камнями не работали, когда я в прошлый раз проверял.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Прохожий (??), 04-Янв-22, 10:46
	Много ты знаешь пользователей, которые сами драйвера поправляют?
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Смузихлёб (?), 04-Янв-22, 16:50
	> Много ты знаешь пользователей, которые сами драйвера поправляют? Та даже системный программист не сможет это сделать не имея на руках спецификации от производителя железа.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (103), 04-Янв-22, 18:02
	>> Много ты знаешь пользователей, которые сами драйвера поправляют? > Та даже системный программист не сможет это сделать не имея на руках > спецификации от производителя железа. Спеки? Т.е. ситуации, когда уже есть драйвер для аналогичного железа не рассматриваем? Или даже для этого же, но вот сломался. Прямо сейчас в ядре есть хаки для различных модификаций, поддерживаемых драйверами. И для обхода багов железа.
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от YetAnotherOnanym (ok), 04-Янв-22, 22:40
	> Много ты знаешь пользователей, которые сами драйвера поправляют? Эээ... ну, я однажды vid&pid в .h-файл добавил. Это считается?
	Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

	364. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от DyadyushkaAU (ok), 05-Янв-22, 15:55
	Сколько в итоге денег сэкономили? А сколько времени ушло на то, чтобы разобраться с языком программирования вообще и конкретным драйвером в частности? СтОило оно тех усилий с экономической точки зрения?
	Ответить | Правка | Наверх | Cообщить модератору

	387. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Янв-22, 16:36
	> Сколько в итоге денег сэкономили? По сравнению с каким вариантом? > А сколько времени ушло на то, чтобы разобраться с языком программирования вообще и конкретным драйвером в частности? С основами языка - около месяца на 2м курсе, лет за двадцать с гаком до описываемых событий. С конкретным драйвером - несколько вечеров. > СтОило оно тех усилий с экономической точки зрения? Опять-таки, смотря как считать. Вариант с перебором аналогов (каждый из которых стОит денег, плюс ожидание доставки, плюс чип внутри заранее неизвестен и может оказаться неподдерживаемым вообще) - этот вариант с экономической точки зрения намного лучше?
	Ответить | Правка | Наверх | Cообщить модератору

	392. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 06-Янв-22, 18:01
	> По сравнению с каким вариантом? По сравнению с покупкой нового девайса, который бы работал без переделки драйвера. Мы же в этом контексте находимся. > Опять-таки, смотря как считать. Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц. На доработку драйвера старого ушло X денежных единиц. Если N > X, то вы потратили деньги и время впустую (разве что удовольствие получили от самого процесса, но мы подобные вещи не будем брать в расчёт, потому что это выходит за рамки обсуждаемой темы).
	Ответить | Правка | Наверх | Cообщить модератору

	393. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 06-Янв-22, 18:11
	> Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц. Но как обычно - только в теории. Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под себя". Как и повышенные налоговые и соц. отчисления на "заработал денег больше суммы X" и проч.
	Ответить | Правка | Наверх | Cообщить модератору

	396. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 06-Янв-22, 19:09
	>> Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц. > Но как обычно - только в теории. Для подавляющего большинства пользователей, не занимающихся профессионально разработкой драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика. > Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под  себя". Старый девайс выбирался аналогичным образом. Поэтому здесь паритет и этим временем можно пренебречь. > Как и повышенные налоговые и соц. отчисления на "заработал денег больше суммы X" и проч. Если речь идёт о дополнительном заработке (за вычетом налогов) - что здесь может быть плохого?
	Ответить | Правка | Наверх | Cообщить модератору

	399. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 06-Янв-22, 21:28
	>>> Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц. >> Но как обычно - только в теории. > Для подавляющего большинства пользователей, не занимающихся профессионально разработкой > драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика. Практика, которая "проста" только у теоретиков. >> Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под  себя". > Старый девайс выбирался аналогичным образом. Поэтому здесь паритет и этим временем можно пренебречь. Если рассматривать покупки, как независящие сферическо-вакуумные события - все может быть. Однако, вне вакуумной сферы, если старый девайс прослужит дольше, то новый покупается позднее и в итоге выходит N девайсов для временного отрезка t, против N-X для такого же отрезка, при этом следует учитывать не только стоимость этих X девайсов, но и затраты времени на "вникнуть, что сейчас есть на рынке, что хорошо, а что фуфло" и прочее. >> Как и повышенные налоговые и соц. отчисления на "заработал денег больше суммы X" и проч. > Если речь идёт о дополнительном заработке (за вычетом налогов) - что здесь может быть плохого? Во-первых, такой возможности на основной работе может и не быть, а искать и оформлять подработку - тоже нужно время. Во-вторых - налоги и отчисления за это дело могут "неприятно" удивить, т.е. тупо взять свою почасавую плату П и посчитать "если я проработаю на Ч часов больше, то получу Ч*П" -- не выйдет. Поэтому да, "просто было на бумаге, но забыли про овраги!"
	Ответить | Правка | Наверх | Cообщить модератору

	406. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 08-Янв-22, 00:02
	>> Для подавляющего большинства пользователей, не занимающихся профессионально разработкой >> драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика. > Практика, которая "проста" только у теоретиков. И в чём здесь могут быть сложности? Обычный пользователь считает, что он реально может, что обойдётся ему дешевле, тот вариант и выбирает. Зачастую это выкидывание старой несовместимой с новой ОС железяки и покупка нового девайса. >>> Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под  себя". >> Старый девайс выбирался аналогичным образом. Поэтому здесь паритет и этим временем можно пренебречь. > Если рассматривать покупки, как независящие сферическо-вакуумные события - все может быть. Если рассматривать покупки с точки зрения обычной логики, то что на выбор старого девайса человек тратил время, что на выбор нового он также потратит время. Эти временные промежутки при одном и том же классе устройств примерно одинаковы, то есть имеем полный паритет. > Во-первых, такой возможности на основной работе может и не быть, а искать и оформлять подработку - тоже нужно время. Если нет возможностей на основной работе, то о каких дополнительных заработках и последующих налогах вы вообще говорили? Может тред перечитаете, прежде чем бессвязно отвечать?
	Ответить | Правка | Наверх | Cообщить модератору

	407. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (-), 08-Янв-22, 02:00
	>>> Для подавляющего большинства пользователей, не занимающихся профессионально разработкой >>> драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика. >> Практика, которая "проста" только у теоретиков. > И в чём здесь могут быть сложности? В расхождении подсчета "на пальцах" и _реального_ результата. Ваш Кэп > Если рассматривать покупки с точки зрения обычной логики, то что на выбор > старого девайса человек тратил время, что на выбор нового он также > потратит время. Эти временные промежутки при одном и том же классе > устройств примерно одинаковы, то есть имеем полный паритет. Т.е. "мы можем дольше использовать старое устройство, следовательно количество покупок, как и затраченного ни них времени в общей сумме - будет меньше" вы просто проигнорировали ... >> Во-первых, такой возможности на основной работе может и не быть, а искать и оформлять подработку - тоже нужно время. > Если нет возможностей на основной работе, то о каких дополнительных заработках и > последующих налогах вы вообще говорили? Может тред перечитаете, прежде чем бессвязно отвечать? Потрудитесь расширить кругозор, прежде чем бросаться заявлениями, ну и читать не только по одному предложиению, что ли. В зависимости от страны проживания, помимо налогов есть отчисления на соц. пакет (пенсия, медстраховка), плюс разные страховки со стороны работодателя. И нередко - "ступеньчатое", т.е. если вы заработали больше определенной суммы - будет другой "процент". Плюс есть определенные суммы, не облагаемые налогом и это учитывается уже при рассмотре Вашей налоговой декларации (т.е. уже в следующем году). Поэтому, без обращения к налоговому консльтанту, вполне может оказаться так, что заработали вы вроде бы на 1000 у.е. больше, но получили в итоге на 500 у.е. меньше. И выяснится это только через полгода-год.
	Ответить | Правка | К родителю #406 | Наверх | Cообщить модератору

	411. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 08-Янв-22, 11:17
	> Т.е. "мы можем дольше использовать старое устройство, следовательно количество покупок, > как и затраченного ни них времени в общей сумме - будет > меньше" вы просто проигнорировали ... Да, пропустил, извиняюсь. Но что это меняет в корне? Текущее положение дел таково, что потребитель (обычный, не профессионал или гик) как менял старый девайс на новый, так и будет продолжать это делать, потому что затраты на исправление драйверов в подавляющем большинстве случаев не окупятся (что по времени, что по деньгам). Новый девайс будет и на гарантии, и лучше старого (быстрей, функциональней). Соглашусь, что в какой-то гипотетической реальности это может быть не так (налоги, время на поиски и так далее). Но в объективной реальности от старого хлама при наличии ресурсов избавляются. А вот тем одним процентом анонимусов, любящих поковыряться от нечего делать в дровах этого хлама можно спокойно пренебречь. Или у вас какая-то другая статистика? Если да, хотелось бы подробностей.
	Ответить | Правка | К родителю #407 | Наверх | Cообщить модератору

	394. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Янв-22, 18:58
	> который бы работал Кто может это гарантировать заранее? > стОит N денежных единиц Плюс N' денежных единиц за выкинутый старый девайс, на допиливание драйверов которого мы решили не тратить время, плюс потерянное время на ожидание доставки нового девайса, плюс время на выяснение ситуации с драйверами для нового девайса. И это, замечу, без какой-либо гарантии, что новый девайс будет "работать без переделки драйвера".
	Ответить | Правка | К родителю #392 | Наверх | Cообщить модератору

	395. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 06-Янв-22, 19:06
	> Кто может это гарантировать заранее? Очевидно, что производитель девайса. > Плюс N' денежных единиц за выкинутый старый девайс Минус амортизация. > потерянное время на ожидание доставки нового девайса, Это время ничего не стоит, если только речь не идёт об упущенной выгоде. Если всё-таки идёт, то новые девайсы в таких случаях покупаются заранее. > плюс время на выяснение ситуации с драйверами для нового девайса Оно обычно несоизмеримо меньше времени доработки драйвера для старого устройства. > И это, замечу, без какой-либо гарантии, что новый девайс будет "работать без переделки драйвера". Производитель обычно даёт такую гарантию. В 99 процентах случаев она работает, хотя в принципе бывает всякое.
	Ответить | Правка | Наверх | Cообщить модератору

	400. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от YetAnotherOnanym (ok), 07-Янв-22, 00:52
	> Очевидно, что производитель девайса. Разве Вам никогда не встречались устройства, производитель которых обеспечивает только драйвера для Windows? Ну так они бывают, медицинский факт. И драйвера для Linux пишут умельцы-энтузиасты - хорошо, если есть спеки на чип и в сарае дядюшки Ляо просто клепают платы референсного дизайна, без отсебятины. > Минус амортизация. Амортизация считается, емнип, если стоимость имущества переносится на выпускаемую продукцию/услугу. Если оборудование не работало из-за отсутствия драйверов, то потраченная на его покупку сумма - это просто убыток. > Это время ничего не стоит Спасибо. Я польщён. > Оно обычно несоизмеримо меньше времени доработки драйвера для старого устройства. Опять-таки, зависит от. Бывает, что воткнул - заработало, а бывает, что и с бубном поплясать приходится. > Производитель обычно даёт такую гарантию. В 99 процентах случаев она работает, хотя > в принципе бывает всякое. Дык отож...
	Ответить | Правка | Наверх | Cообщить модератору

	405. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 07-Янв-22, 23:45
	> Разве Вам никогда не встречались устройства, производитель которых обеспечивает только драйвера для Windows? Встречались. И? Не понимаю, к чему вы клоните. Напоминаю, я вступил в дискуссию после вот такого заявления Анонимуса: "Просто с линуксом у анонима есть опция поправить что-то самому, а с вендой через пару лет после покупки всё железо отправляется на помойку". > Амортизация считается, емнип, если стоимость имущества переносится на выпускаемую продукцию/услугу. Если оборудование не работало из-за отсутствия драйверов, то потраченная на его покупку сумма - это просто убыток. Ранее речь шла о том, чтобы поправить драйвер для старой железяки (которая, надо полагать, уже отработала свой срок, отсчитанный производителем) под новую ОС. Почему вы теперь говорите, что оборудование не работало? >> Это время ничего не стоит > Спасибо. Я польщён. Я не собирался вам льстить, и ваш сарказм в данном случае не совсем понятен. Время ожидания бесплатно. Это просто констатация факта. > Опять-таки, зависит от. Бывает, что воткнул - заработало, а бывает, что и с бубном поплясать приходится. В подавляющем большинстве случаев всё работает сразу при использовании сертифицированной ОС. Если что-то не работает, то вам в любом случае придётся танцевать с бубном: 1. Или чтобы поставить драйвер. 2. Или чтобы поправить исходный код драйвера. С моей точки зрения вероятность того, что время на исправление исходного кода драйвера хотя бы сравняется со временем на попытку поставить драйвер, стремится к нулю. > Дык отож... 1% не оправдывает возню с исходным кодом драйвера. Проще железку поменять, чем и занимаются в подавляющем числе обычные пользователи-непрофессионалы. Вы - скорее исключение из правил, чем правило. Следовательно опция по предоставлению анонимусу опции что-то поправить самому не оправдана.
	Ответить | Правка | Наверх | Cообщить модератору

	278. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:50
	> Если оно вообще будет работать, например, усб звуковухи с амдшными камнями не работали, > когда я в прошлый раз проверял. Да какие там звуковухи -- вон захотели тут давеча ноут с этой их хвалёной win10 в локалку кабелем подключить, своего Ethernet на нём не оказалось, а два оказавшихся под рукой dlink (сотка и гигабит на распространённых чипах, в линуксе что десять лет назад работали, что сейчас) -- "ой, не вижу, поискать в интернете?". Занавес.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	295. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от Смузихлёб (?), 04-Янв-22, 19:31
	Я человек простой, вижу шигорина, ставлю диз даже не читая.
	Ответить | Правка | Наверх | Cообщить модератору

	309. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от YetAnotherOnanym (ok), 04-Янв-22, 22:38
	IT-специалиста, способного купить ноут без eth-разъёма, надо гнать с фирмы тряпками, а не usb-адаптер ему подбирать.
	Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

	149. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Аноним (149), 03-Янв-22, 17:56
	Вакцины от Windows 11 несуществует, мои соболезнования вашим родным и близким.
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	245. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
	Сообщение от pavlinux (ok), 04-Янв-22, 14:23
	> По хорошему нужно раз в несколько лет переписывать всё с нуля > с оглядкой на актуальное железо, а не тянуть гору костылей, прослоек и надстроек. Рожай каждый год нового ребенка, зачем тебе старые, 2-,3-,4-,5-летние дети?
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	256. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Смузихлёб (?), 04-Янв-22, 16:48
	> Рожай каждый год нового ребенка, зачем тебе старые, 2-,3-,4-,5-летние дети? Это какой понос вместо мозгов должен быть чтобы проводить подобные аналогии. Жаль тебя, дядя.
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:46
	> чтобы проводить подобные аналогии Уж не знаю, какой у _Вас_ понос вместо мозгов -- но Вас макнули носом именно в то, что порождаемый Вами и Вам подобными однодневный хлам через год уже "устарел" и нафиг никому не нужен; а то, во что действительно вложены время, силы, душа -- и через сорок лет мило и дорого. Не спешите отбрёхиваться.  Подрастёте -- поймёте, жизнь так устроена.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
	Сообщение от Смузихлёб (?), 04-Янв-22, 19:32
	> то, во что действительно вложены время, силы, душа -- и через сорок лет мило и дорого Именно поэтому ты сидишь на core 2 duo в 2к22 году? Мило, лол.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 04-Янв-22, 13:23
	Конечно, хорошо, что нашёлся очередной Геракл. Но не лучше бы было просто не доводить до такого, используя более современные и адекватные языки?
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	374. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (330), 05-Янв-22, 18:06
	А, да, святой Rust эту проблему решит на раз плюнуть.
	Ответить | Правка | Наверх | Cообщить модератору

	384. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от DyadyushkaAU (ok), 06-Янв-22, 13:19
	Может и не на раз плюнуть, но точно с меньшим количеством ошибок работы с памятью и последующей вознёй с их отловом. Плюс масса других вкусных плюшек из коробки.
	Ответить | Правка | Наверх | Cообщить модератору

139. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–4 +/–
Сообщение от ананоша (?), 03-Янв-22, 17:08
Скоро Линукс перейдет на zig и ее сборочную систему
Ответить | Правка | Наверх | Cообщить модератору

	158. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (-), 03-Янв-22, 18:25
	make menuconfig тебя не одобряет.
	Ответить | Правка | Наверх | Cообщить модератору

164. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–4 +/–
Сообщение от Аноним (164), 03-Янв-22, 18:58
>make -j96 Лишь бы ninja не использовать.
Ответить | Правка | Наверх | Cообщить модератору

	379. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
	Сообщение от Аноним (-), 05-Янв-22, 23:51
	> Лишь бы ninja не использовать. Лучше не использовать вне локалхоста, тормозное г..но
	Ответить | Правка | Наверх | Cообщить модератору

167. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–2 +/–
Сообщение от смешнох (?), 03-Янв-22, 19:47
Опять у сквирти обострение. Ну, хорошо что залогинился, родной.
Ответить | Правка | Наверх | Cообщить модератору

179. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
Сообщение от Аноним (180), 03-Янв-22, 21:21
> make -j96 vmlinux Спасибо проорался. Такое количество ядер ни одному гентушнику недоступно.
Ответить | Правка | Наверх | Cообщить модератору

	279. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–3 +/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:52
	Среди моих знакомых гентушников есть минимум один бывший админ нескольких вузовских кластеров, который и сейчас, думаю, без проблем столько получит при надобности (правда, на сервере под альтом, но это уже технические подробности). :)
	Ответить | Правка | Наверх | Cообщить модератору

	426. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (426), 11-Янв-22, 19:52
	Не важно. Gentoo в chroot можно собирать хоть под Ubuntu, хоть под MX Linux.
	Ответить | Правка | Наверх | Cообщить модератору

190. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
Сообщение от Ананоним (?), 03-Янв-22, 23:19
Наконец-то кто-то хорошо показал весь бардак в исходниках ядра :) Я когда первый раз туда заглянул, очень грустно мне стало.
Ответить | Правка | Наверх | Cообщить модератору

208. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+2 +/–
Сообщение от iCat (ok), 04-Янв-22, 07:58
50-80% Это довольно свирепо...
Ответить | Правка | Наверх | Cообщить модератору

229. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
Сообщение от Аноним (229), 04-Янв-22, 12:23
>ускоряющих сборку ядра Linux на 50-80% и че теперь делать?
Ответить | Правка | Наверх | Cообщить модератору

	427. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (426), 11-Янв-22, 19:53
	Компилять
	Ответить | Правка | Наверх | Cообщить модератору

244. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
Сообщение от pavlinux (ok), 04-Янв-22, 14:19
Смотрю в теме одни дистростроители собрались, что не х..., то свой дистриб. А в реальности: apt upgrade. :D
Ответить | Правка | Наверх | Cообщить модератору

	280. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:53
	...из бинарного демьяна? ;-} С наступившим!
	Ответить | Правка | Наверх | Cообщить модератору

	422. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (422), 10-Янв-22, 19:29
	А ты сам-то кто?
	Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

	428. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (426), 11-Янв-22, 19:57
	А то нет? Берёшь howto от какого-нибудь "Линукс для себя" и вперёд.
	Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

254. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
Сообщение от Аноним (254), 04-Янв-22, 16:38
Ага, убираем поддержку rust и станет ещё быстрее.
Ответить | Правка | Наверх | Cообщить модератору

	326. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от . (?), 05-Янв-22, 11:31
	да просто отключаешь в конфиге сотни ненужных тебе драйверов
	Ответить | Правка | Наверх | Cообщить модератору

	331. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
	Сообщение от Аноним (330), 05-Янв-22, 12:18
	Да какую сотню? Один-два учебных.
	Ответить | Правка | Наверх | Cообщить модератору

316. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%"	–1 +/–
Сообщение от pavlinux (ok), 05-Янв-22, 05:20
>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. Каким раком дебажная функция нужна для ускорения сборки?
Ответить | Правка | Наверх | Cообщить модератору

	378. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%"	+/–
	Сообщение от Аноним (-), 05-Янв-22, 23:49
	ты прочитал > to make it more representative как ускорение ?
	Ответить | Правка | Наверх | Cообщить модератору

324. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+1 +/–
Сообщение от . (?), 05-Янв-22, 11:26
не усложнит ли это понимание единицы компиляции? чистка "неиспользуемых хедеров" - это хорошо. но не всякий перекрёстный нелогичен. если есть в одном хедере второй, перекрёстный тому что в юните уже есть, это не исходит из логики по умолчанию, что в первом должен быть второй. и соответственно его не уберут в будущем.
Ответить | Правка | Наверх | Cообщить модератору

372. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
Сообщение от Аноним (372), 05-Янв-22, 17:07
А почему это не делается/проверяется автоматически?
Ответить | Правка | Наверх | Cообщить модератору

373. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	+/–
Сообщение от Аноним (330), 05-Янв-22, 17:57
Это повод увеличить мажорный номер версии.
Ответить | Правка | Наверх | Cообщить модератору

391. "не нужно"	–1 +/–
Сообщение от фстэк якобы (?), 06-Янв-22, 17:54
не взлетит. подумаешь, время компиляции. вон, раст компилируется часами, никто и в ус не дует. главное, дети мои, чтоб вы не путались в своих исходничках. чтоб понимали свое творчество, через годик. Документировали, чтоб иной подаван не строил из себя гения фоне вашего кода. время компиляции тут вообще не имеет роли
Ответить | Правка | Наверх | Cообщить модератору

404. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."	–1 +/–
Сообщение от pavlinux (ok), 07-Янв-22, 20:54
Кароч, три дня трахал, компилится быстро, только не грузится. :)
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема