Инго Молнар (Ingo Molnar), известный разработчик Linux ядра и автор планировщика задач CFS (Completely Fair Scheduler), предложил для обсуждения в списке рассылки разработчиков ядра Linux серию патчей, затрагивающих более половины всех файлов в исходных текстах ядра и обеспечивающих увеличение скорости полной пересборки ядра на 50-80% в зависимости от настроек. Реализованная оптимизация примечательна тем, что она сопряжена с добавлением самого крупного в истории разработки ядра набора изменений - для включения разом предложено 2297 патчей, меняющих более 25 тысяч файлов (10 тысяч заголовочных файлов в каталогах "include/" и "arch/*/include/" и 15 тысяч файлов с исходными текстами)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56449
Титанический труд, да...
Очень надеюсь, что с принятием такового затягиваться не будет, потому что иначе всю работу придётся проделать второй раз.
скорее всего будут, так как проверить это все не так быстро. Придется ждать ревью от маинтейнеров всех затронутых подсистем и т.д.
И это первый шаг.
Когда разгреб первую гору навоза. Выльется ещё 10.
А раньше эти 10 не замечали.
Так как кто раньше уходил разгребать - не возвращался.
Эффект выжившего.
Теперь главное что сам линтер был написан высокоуровнево. И сам не превратился в дракона с золотыми цепями совместимости.
Согласен, - чувак просто монстр!!!
p\s Когда изучал libc, в частности picolibc, тоже обратил внимание, что там бардак с заголовками,
+ туева куча одинаковых макросов, по хорошему место которым в одном файле. Решил начать всё это рефакторить, но интузиазм быстро пропал:( - за бесплатно таким заниматься такое себе удовольствие:))
p\p\s вот что бывает когда, весь проект это по сути этакий копи-паст из других проектов, или когда нет четкого стиля для проекта, - да там, даже в одной функции можно было увидеть, что она была составлена из кусков которые писали разные люди:)))
Конечно примут. Это же кого надо патчи.
А что, вы отправляли патчи, и их не принимали? Расскажите подробнее.
reiser4?
Тебя простить может только что ты лежал в криосне. И сейчас пробудился. Потмоу что через один новость на опеннете о том как приняли или не приняли очередной патч. Вот Инго упоминаемый тут в ядро внес вклад. А вот Кон не внес. Рядом рассказывают как принимают ксмбд. А недалеко уже неизвестно какой раз пытаются бить на патчи автор ваергварда. Тут же недалеко всё что было до селинуха отправили лесом. И прочая, прочая. Ты на самом деле не в курсе как это происходит уже пару десятков лет?
А у комментария ещё есть прекрасный маркерок. Уровень деградации опеннетчиков.
Деградация -- это когда пытаешься судить о чём-то исключительно со слов рабиновича, музыки рабиновича?..Если что, с моим участием в ядро патчик запихивали. Месяца три висела бага, затем пару недель лежало письмо, потом его заметили -- и буквально за ночь в краткой переписке замержили.
О том, что со сложными патчсетами нетривиальные люди могут годами стучаться (до того вложившись в их наработку) -- разумеется, тоже знаю. Но то же ГОСТовское шифрование в ядро коллеги (точнее, vt@altlinux) вполне себе дотащили.
Конечно рабиновичи мне напели. Миша уж кому-кому а тебе бы по этому поводу не говорить. Как там етцнет, втянули во все ведущие дистры? Как там кастэл с рсбаком что вы собирали, успешно применен в ядре и дистрах? Все патчи с рпм альтового уже втянули в апстрим? Как там опенволовские патчики, приняты безоговорочно? А рядом, например, ваергвард который порвали на куски и впихнули непойми как в ядро.> Но то же ГОСТовское шифрование в ядро коллеги (точнее, vt@altlinux) вполне себе дотащили.
Очень смешно. Сколько там браузеров гостовое шифрование поддерживает? Полторы калеки? Один яндексовый, второй хромиум с патчами который регулярно при пересборке перестает нормально работать.
Гляди-ка, нашелся конспиролог круче Шигорина, хотя казалось бы, куда уж круче-то.
А лгать прилюдно не стыдно? Простые факты доступные для проверки всем называть конспирологией может только больной человечек. У тебя там с сознанием всё в порядке? Или ты за новогодние праздники расширил его чересчур? Так в режим пора уже входить, почитай что-нибудь умное.
> Простые факты доступные для...веры всем конспирологам. Поправил, не благодари.
> Очень надеюсь, что с принятием такового затягиваться не будет,Будут. В описании патчсета Инго настойчиво повторяет, что это RFC, то есть request for comments от сообщества. И его дальнейшие планы на тот случай, если в целом linux выскажет готовность пойти на принятие такого -- это допиливать сие в отдельном дереве, с тем чтобы основную часть работы выполнить до мерга в мейнстрим, оставив на потом лишь ловлю блох.
> потому что иначе всю работу придётся проделать второй раз.
Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. Что требует конечно времени, но существенно меньше, чем можно было бы подумать. Во-вторых, есть шансы, что сейчас кто-нибудь подключится, и, допустим, пока Инго продолжает выпиливать, кто-то другой будет заниматься rebase'ами.
> Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты. Что
> требует конечно времени, но существенно меньше, чем можно было бы подумать.В таких изменениях разгребать конфликты иногда не проще создания с нуля. Когда я делал похожее в намного меньшем проекте, то автоматизировал бОльшую часть работы, иначе и ошибок было б намного больше, и переделывать надо было бы несколько раз
> Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты.Это ядро. Тут патчи принято приводить к нужному виду, а не коммиты таскать. Сейчас в отдельной ветке проведут ревью (уже обговорили в рассылке), протестят, подправят, оформят новым набором патчей с меньшим их числом (автор уже сказал что 70% можно в один).
>> Нет. Во-первых, это же git, делаешь rebase и вперёд разгребать конфликты.
> Это ядро. Тут патчи принято приводить к нужному виду, а не коммиты
> таскать.Коммиты и есть патчи, только хранимые в git.
> Коммиты и есть патчи, только хранимые в git.Удивительно. Только прежде чем их примут в ядро, ты десять раз переделаешь их. Именно переделаешь, а не добавишь ещё несколько коммитов.
>> Коммиты и есть патчи, только хранимые в git.
> Удивительно. Только прежде чем их примут в ядро, ты десять раз переделаешь
> их. Именно переделаешь, а не добавишь ещё несколько коммитов.И чё?
Скорее всего затянется. Мне чтобы заставить работать этот набор патчей пришлось написать еще несколько своих патчей. Плюс ядро у меня ловило кернелпаник.
....
я руками собираю
Почему сишники за 50 лет не догадались сделать модульную систему как в Яве? Каждый компиляйшон юнит требует парсинга сто шессот файлов. В каком нибудь Дельфи жмещь запустить - и сразу запускается
Сразу видно, что серьёзных проектов на Дельфи у тебя не было :D
Потому, Delphi компиляет отдельные юниты в отдельные независимые модули (которые даже если и лежат в итоге в одном бинарнике - по сути, как набор отдельных взаимодействующих библиотек). А "Ява" - это вообще виртуальная машина, у неё вообще никаких гарантий на время выполнения нет. Одна и та же строчка кода может работать как 1, так и 1000 единиц времени.В случае с Си, из-за того, что язык используется для системного программирования - требуются гарантии детерминированности времени исполнения кода. И если Delphi программа может позволить себе "подождать" несколько миллисекунд на то, чтобы подгрузить страницы другого модуля, инициализировать его и т.д., то если у тебя в обработчике прерывания в ядре начнёт происходить недетерминированная хрень и логика-отсебятина компилятора - то ядро просто работать не будет.
В си тоже вполне себе есть "модули". Библиотеки (статические и динамические) - это именно про это. Если ты разбиваешь свой проект на отдельные незавимые библиотеки - то чаще всего их можно собирать
и редактировать каждый по отдельности, и пересборка всего проекта не требуется. И даже ядро умеет динамически линковаться с кодом - kernel objects - это именно про это. Просто из-за особенностей ядерной разработки - одна правка в базовое ядро может сломать модули, собранные под старое ядро, причём самым неожиданным образом (т.к. всё работает в одном адресном пространстве, промахнулся на 1 байт в структуре - и ты уже, например, корраптишь данные файловой системы). Поэтому дешевле не портить себе нервную систему и не стрелять в ногу - так что ядро пересобирают целиком.Ну, а то, что некоторые сишники и плюсовики (например, проект Chromium) закидывают всё в один проект и делают монолитные проекты на 60 миллионов строк кода которые компиляются в районе суток - это уже проблема рук, растущих не из того места, а не языка.
Что за дичь ты написал? Особенно доставило про делфи и инициализацию модулей.
Некоторые недостатки других ЯП и компиляторов, никак не оправдывают конченную модульность в C/C++
Потому что это именно так и устроено - каждый дельфёвый модуль - это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой набор функций и использует функции других библиотек. Т.е. ничем концептуально не отличается от проекта на си, состоящего из нескольких десятков статически слинкованных библиотек. Когда пишешь на C - тебе не приходится пересобирать каждый раз glibc с проектом.На сях обычно каждый C-файл не делают отдельной библиотекой. Во-первых, потому что растут накладные расходы, софт становится медленнее. А во-вторых, это закрывает целый ряд оптимизаций, который возможен в gcc (в том числе link-time optimization), но не возможен в Delphi, потому что МОДУЛЬНОСТЬ.
> Потому что это именно так и устроено - каждый дельфёвый модуль -
> это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой
> набор функций и использует функции других библиотек. Т.е. ничем концептуально не
> отличается от проекта на си, состоящего из нескольких десятков статически слинкованных
> библиотек. Когда пишешь на 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/C++
>C/C++Это что за язык такой?
Он даже не в курсе, что это два разных языка. Просто второй скопипастил у первого, но как-то не очень уверенно и криво. Даже разные фишки выкидывать пришлось ради "святого ООП", который по факту просто макрос для вызова функций с контекстом (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях).
> restrict появился в c99
> (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях).Экспердус опеннетус вульгарис ...
Это два языка. Никогда не видел перечисление косой чертой?
В Юникс мире такого перечисления никто не знает.
> закидывают всё в один проект и делают монолитные проекты на 60 миллионов строк кода которые компиляются в районе сутокНу зайди в билд систему любого дистра и убедись, что неоправданно долгая компилюха - это болезнь вообще всех сишных проектов. Перейдя в Линукс, в свое время удивился, как обычный gtk.-хелловорлд компилился секунды, а не наносекунды, как в Дельфи.
Я гентушник, мне не надо "заходить в билд систему", она у меня прямо на компе.Я не сказал, что софт компиляется быстро. Сишные проекты действительно собираются ощутимо долго.
> проблема рук, растущих не из того места, а не языка.Следовательно, таки языка, а не рук.
А если бы хоть раз посмотрели машинный код после кодогенератора Дельфи, то удивления бы не было.
>из-за особенностей ядерной разработкиИнтересный эвфемизм для отсутствия архитектуры
Ява же любит кушать память
> Ява же любит кушать памятьПальму первенства по этому свойству она давно отдала Rust'у.
А будут ссылки на доказательства, или ты просто балабол?
Из книжки Rust:
Гарантии безопасности памяти в Rust затрудняют, но не делают невозможным случайное выделения памяти, которая никогда не очищается (что известно как утечка памяти ). Полное предотвращение утечек памяти не гарантируется Rust, так же как не является гарантией отсутствие гонок данных проверенных во время компиляции, а это означает, что утечки памяти безопасны в Rust.В реальности:
Так же как Java безопастный раст может схавать столько памяти, сколько ей дадут или пока не прибьют OOM киллеры, т.к. память течет.
Давай переведу с русского на русский: разработчики Rust предупреждают, что говнокод может течь -- какая неожиданность
Подождите, этот гений однажды узнает, что в Java несмотря на gc тоже возможны утечки памяти, его тогда инфаркт хватит...
https://www.baeldung.com/java-memory-leaks
Так а зачем нам такой безопасный язык- то?
Затем что невозможно избежать утечек памяти. Это как пытаться избежать языковыми средствами возможности зацикливания (проблема останова). Можно, но не будет уже полноты по Тьюрингу.Ошибка здесь такая. Вы утверждаете что ремень безопасности не уберегает от летальных случаев на дорогах и потому не нужен.
>Затем что невозможно избежать утечек памяти.Тогда и не надо было пыжиться, пытаясь заменить C++, Rust отличная замена сишарпа, только вот с такими приколами в нишу сишки с плюсами ему не пролезть.
Сишарп на виртуальной машине работает. Его сравнивать с 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.../
На данный момент он да, избавляет от 99% эксплуатируемых уязвимостей, просто потому, что эксплуатировать нечего и негде.
В твоём г-нокоде - вполне возможно. Google, MS, Huawei, Mozilla, Amazon - уже эксплуатируют вовсю. Разумеется, речь не идёт о полном переписывании с нуля всего и вся, это было бы очень и очень дорого.
>разработчики Rust предупреждают, чтосборка мусора не работает и надо использовать костыли, а криков-то по поводу free() было...
Каким образом выход за скоуп объекта с его немедленным освобождением является костылем? Проще и органичней еще ничего не придумали.
>разработчики Rust предупреждают, что говнокод может течьНа Rust бывает другой код?
>>разработчики Rust предупреждают, что говнокод может течь
> На Rust бывает другой код?У тебя нет, независимо от ЯП.
Но не все люди - ты.
Сомнительное утверждение, учитывая что в Rust нет сборщика мусора, а ресурсы освобождаются автоматически при выходе переменной из области видимости. В теории, конечно можно оперировать сырыми указателями в unsafe блоке, и управлять памятью вручную, но это ничем не будет отличаться от того же C/C++.
Удивительно, но free() не обязательно освобождает ресурсы, а всего лишь возвращает память куче. Потому, когда на "том же же C/C++" пишут специфичные для задачи менеджеры памяти, которые решают проблему фрагментации кучи, "автоматическое освобождение" течёт. А когда все переменные стековые, то получается максимум HelloWorld.
Когда на любой чих делают аллокацию объекта, да еще и в цикле, а потом ява виновата, а не криворукие кодеры.
В джаве так-то можно JVM указать, сколько хипа она максимально может выжрать, прежде чем с ООМ грохнется.
>В джаве так-то можно JVM указать, сколько хипа она максимально может выжратьи как это опровергает фразу "жаба жрёт ОЗУ как свинья помои"? Погугли сколько памяти в жабе занимает Double или Integer )
И, кстати, делать 100500 одноразовых иммутабельных объектов (и массово заниматься их копированием с места на место) - это прямая рекомендация от корифеев многопоточного погромирования на жабе )
Иммутабельность позволяет получить дешевую в поддержке потокобезопасность. Никто не пойдет ковыряться в проекте, где мьютекс на мьютексе и семафором погоняет. Ну может за ОЧЕНЬ большие деньги. А так как у иммутабельных объектов нет стейта, их можно закешировать в пул и возвращать одну и ту же сцыль. Так что все проблемы с аллокацией снова от криворуких кодеров, не могущих в педантичное переиспользование того, что можно переиспользовать. Про Flyweight паттерн еще GoF писали.
P.S. А классы-обертки везде использовать тебя никто не заставляет.
"Нормально делай - нормально будет." (с)
Тем временем не только лишь каждый Java проект размером на 3 порядка меньше собирается быстрее, чем за 130с.
Настоящий Java проект только на скачивание артифактов трати больше чем 120 сек
У нас серверок был, логики не очень много и полностью кастомная, на джава.И там были зависимости на апач либы разной бигдата направленности. И эта помойная параша без локального кеша с быстрого прокси в сети качала зависимости 1.5 часа. Оно писало сотни тысяч мелких и больших файликов, делало миллионы запросов на ьедное прокси. С локальным кешом собиралось 30 минут. Что бы не страдать во время локального девелопмента я на начале спринта регулярно запускал скрипт, который собирал свежие зависимости и хардкодом записывал их во все возможные анналы класспаса, и чистил зависимости. Таким образом сборка кода и артефактов для установки занимала 10 минут.
> В каком нибудь Дельфи жмещь запустить - и сразу запускаетсяС Бейсиком не попутали?
Да и не с каждым Бейсиком прокатит, Power Basic к примеру тоже компилировать сперва прийдется
Кстати разработчики Delphi реально всегда выпячивали скорость компиляции, как главное преимущество над C++. Явное разделение интерфейса и имплементации позволяло делать очень быстрые однопроходные компиляторы.
На момент выхода Делфи скорость компиляции равноценных проектов переписанных с Си действительно отличалась на порядки, но это ж было аж на 386 процессорах и жесткими дисками даже без DMA.
В то время и я писал на Делфи не смотря на паталогическое неприятие Паскаля.
Логично, когда скорость компиляции Делфи на реальных проектах перестала быть ключевой особенностью, а среда разработки закостенела, тут от нее массово и отказались.
Тормозное выполнение с гигабайтами памяти или тормозная сборка? что важнее конечному пользователю эклипса, андроида и прочих тормозных продуктов ява мира? Но на пользователей уже всем плевать, хренак хренак в продакшн и лишь бы побыстрее. потом просто сменим обои, кнопки - главное есть видимость улучшения.
Потому что, когда придумывали Си, не было гигабайтов памяти. И даже мегабайтов не было.
> Потому что, когда придумывали Си, не было гигабайтов памяти. И даже мегабайтов не было.Си придумали как заменитель ассемблера (который на каждой машине в 1970-х годах был свой), чтобы перенести Unix с одной машины (устаревающей не по дням, а по часам) на новую машину. "Быстро и грязно" — было в порядке вещей для C того времени.
>"Быстро и грязно" — было в порядке вещей для C того времени.это и сейчас в порядке вещей, для всего
Не надо преувеличивать. Может вы и не заметили, но некоторые вещи меняются к лучшему. Возьмём, к примеру, Rust. Там и модули есть, и с памятью работа корректная. Хотя некоторые программисты на Си к грязи настолько привыкли, что уже и не замечают, как они по макушку в ней увязли. Для них это уже естественное состояние. А потом появляются Геркулесы (наподобие того, что в новости) и пытаются хоть как-то расчистить то, что накопилось.
>Возьмём, к примеру, Rust.Никто не преувеличивает. Раст мог выйти в 2030 году проработанным и стандартизированным, но такого хайпа он мог уже и не поднять и остался бы без поддержки.
Но его сляпали быстро и грязно, а теперь постепенно допиливают. В каждой новой версии старая грязь остается во имя обратной совместимости.
Спорить насколько "грязно", я не буду.
В каждой новой версии старая грязь остаётся только... в старой редакции. Другими словами, это настраиваемо, хочешь ли ты тащить эту грязь в свой новый проект (для какой-то обратной совместимости), или ограничишься свежайшей редакцией. Поэтому можно смело заявлять, в Rust НЕТ грязи.
вы каждый день начинаете новый проект? ;)
Ваш проект тоже может быть сделан быстро и грязно и у вас сейчас полно других более насущных проблем, чем настраивать концентрацию расто-грязи.Да даже то, что раст использует llvm говорит об упомянутом подходе -- это было быстро, т.к. взяли готовое и в то же время грязно, т.к. всякие достоинства раста на это готовое не распространяются
> Ваш проект тоже может быть сделан быстро и грязно и у вас
> сейчас полно других более насущных проблем, чем настраивать концентрацию расто-грязи.Причём здесь какой-то отдельной взятый проект? В случае с C, C++ вы по умолчанию тащите весь накопленный "багаж знаний" компилятора. Rust же вас ограничивает в этом багаже: вы в одном и том же коде не можете применять разные техники и разные стандарты, как в случае с C++.
О какой "расто-грязи" в таком случае вы вообще говорите?> Да даже то, что раст использует llvm говорит об упомянутом подходе
Смешались в кучу кони, люди. Причём здесь LLVM?
--
> это было быстро, т.к. взяли готовое и в то же время грязно, т.к. всякие достоинства раста на это готовое не распространяютсяЕму и не надо распространяться. Компилятор Rust надаёт вам по рукам ДО ТОГО, как дело дойдёт до компиляции в машинный код.
> В случае с C, C++ вы по умолчанию тащите весь накопленный "багаж знаний" компилятора.не-а — у меня лишь нет препятствий тащить
> О какой "расто-грязи" в таком случае вы вообще говорите?
о той, которую надо или переписывать, или она вынуждает привязываться к редакции. Если все всё могут переписать, то смысла в редакциях особо нет
> Смешались в кучу кони, люди. Причём здесь LLVM?
он ведь все еще используется? Ну там "Rust compiles to LLVM" и т.п.
> Компилятор Rust надаёт вам по рукам ДО ТОГО, как дело дойдёт до компиляции в машинный код.
а мне не нравится, что Rust не надавал по рукам тем, кто писал реализации алгоритмов оптимизации и компиляции/трансляции в машинный код. Идеальный, чистый и проверенный код на расте обрабатывается грязным бэкендом, который в результате может добавить непонятных и трудноотлавливаемых ошибок
PS: мы начали с того, что вам не понравилось мое общее высказывание по поводу "быстро и грязно"
>Не надо преувеличивать. Может вы и не заметили, но некоторые вещи меняются к лучшему. Возьмём, к примеру, Rust…1. я так же заметил, что многие вещи меняются к лучшему во многих областях (языках, проектах) и даже C/C++ тут не исключение
2. понятия "нормы" или "грязи" меняются или, что еще хуже, они хорошо сдобрены маркетинговой чепухой. Сейчас ведь стало нормой писать жручие и падучие приложения, т.к. "контейнер в облаке перезапустится в N миллисекунд" или "планка памяти стоит как две чашки кофе" — программисты прошлого схватились бы за голову от такого.
3. "грязь" есть везде: где-то из-за незнания или неопытности, где-то из-за недостатка времени. Про то, что спорить про ее концентрацию я не намерен я уже писал
4. больше ни слова про раст и c/c++ :)
> не-а — у меня лишь нет препятствий тащитьО чём я и говорил ранее. Программисты увязли по макушку в грязи, и этого не замечают. :)
> о той, которую надо или переписывать, или она вынуждает привязываться к редакции. Если все всё могут переписать, то смысла в редакциях особо нет
Подмена понятий, ясно-понятно.
> он ведь все еще используется? Ну там "Rust compiles to LLVM" и т.п.
Да. И?
> а мне не нравится, что Rust не надавал по рукам тем, кто писал реализации алгоритмов оптимизации и компиляции/трансляции в машинный код. Идеальный, чистый и проверенный код на расте обрабатывается грязным бэкендом, который в результате может добавить непонятных и трудноотлавливаемых ошибок
Есть конкретные претензии? Или так, теоретизируем?
Но допустим, что есть. Если вы чем-то недовольны, всегда можно сообщить об этом соответствующей команде. А кто конкретно будет решать найденную вами проблему (команда Rust или команда LLVM), какая уже разница?> 1. я так же заметил, что многие вещи меняются к лучшему
Это не вы заметили. Это я заметил.
> 2. понятия "нормы" или "грязи" меняются или, что еще хуже, они хорошо сдобрены маркетинговой чепухой.
Меняются, да. Но не в сторону полных противоположностей, как вы, видимо, пытаетесь представить.
> Сейчас ведь стало нормой писать жручие и падучие приложения
Только там, где стоимость программиста сильно выше получаемого от его квалификации эффекта. Вы же не думаете, что программирование - это сферический конь в вакууме, искусство ради искусства?
В С++ сделали модули. Лишь слегка медленнее чем fpc...
Точно сделали? Там модули год назад всё порывались принять в стандарт да не приняли. Дальше я не следил
Или речь о динамически линкуемых библиотеках?
модули приняли в С++20, а скоро уже С++23 выходит
> модули приняли в С++20, а скоро уже С++23 выходитАга. В таком виде, в котором они никому не уперлись.
С includ'ами был одна проблема. При перекрестных вызовах методов из двух деревьев невозможно реализовать виртуальные методы возвращающие указатели нужного типа а не базовых.
В модулях это было бы сделать можно, но !!!
Эти, на всю голову больные люди, предусловием поставили отсутсвие перекрестых ссылок в модулях.
Занавес!
Насколько я понимаю, 50 лет назад были маленькие объемы оперативки. А модульность подразумевает компиляцию сразу всех файлов модуля в единое синтаксическое дерево, что позволяет вообще отказаться от include в рамках одного модуля (именно так в C# и Java). Далее, для каждого модуля определяется публичный интерфейс и приватная реализация, и интерфейсы всех модулей проекта должны быть в оперативке (в виде AST) всегда - только так можно избежать постоянной перекомпиляции инклудов (когда один инклуд подключен в тысячи файлов и перекомпилируется тысячи раз вместе с каждым исходником). Вероятно, когда оперативка измерялась килобайтами, сделать все это было затруднительно.
В Си решили поступить по простому - сделали псеводмодульность вручную, т.е. заголовочный файл - это написанный вручную публичный интерфейс. Ну и попались на этом - объемы оперативки стали расти, объемы кода тоже, переписывать язык и весь код уже было нереально, "работает - не трожь" и тому подобное. Кривизна этого подхода особенно явственно вылезла в С++, который унаследовал инклуды Си, а в заголовочные файлы стали пихать шаблонный код.
> модульность подразумевает компиляцию сразу всех файлов модуля в единое синтаксическое деревоНе, как я понимаю, не подразумевает. Если ты, компилируя модуль, будешь генерировать файл типа "скомпилированный модуль", который будет что-то типа комбинации сишных .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-е... какая оптимизация, ты о чём?
Это и так можно делать, достаточно не держать в инклюдах ничего кроме объявлений и порезать использование шаблонов. Но все равно не поможет, так как хотелось бы чтобы линкер пооптимизировал код между объектниками всякими LTO, PGO а может и BOLTом.
Ява вообще тут не к месту переплетена, тут она работает как многие динамические языки лениво подгружая зависимости по мере необходимости.
Когда есть обращение к классу, этот класс ищется в загрузчике классов (в памяти JVM), если не найден, то он ищется в classpath. В том числе по этому "java тормозит", она лениво подгружается после холодного старта, а всякие программки на go и c стартуют практически моментально (когда не требуют загрузки ресурсов с дисков).
Больше патчей для линукса всем пользователями линукса!
Нет нет! не надо нам патчей пиши лучше отличный безглючный код.И лучше на асемблере.
А сопровождать его (код на ассемблере) под каждую архитектуру, ты будешь?
Да я буду сопровождать! Принимаю доллары фунты йены евро.А вы как думали за качественный код на ассемблере надо платить.Привыкли при комуннистах бесплатно.Очнитесь.
Аля гентушники
А всё от того, что в С/С++ нет МОДУЛЬНОСТИ языка Pascal.
Уже есть, но ваш этот спагетти-Linux уже никто не будет в состоянии переписать. Его изначально надо было писать нормально, а там за него первый взялся уже аутист-социофоб в очках, поэтому ядро обречено быть таким монстром
Другие варианты есть?
> Другие варианты есть?Микроядерность.
Смешно
Грустно. Микроядерность требует хорошего проектирования архитектуры, что невозможно в опенсорце
Ну тык Танненбаум же читал курс лекций именно по микроядерности!! Трольвадс в это время на дзюдо ездил ш_т_о_л_е??
Какое дзюдо... Видимо - за пивом и пиццей.
Проблема в том что на х86 тех лет - классическая микроядерная архитектура работало медленно. Правда это решалось, но... Для этого сначала надо спроектировать, а потом - кодить. А не наоборот. Для студента-недоучки - слишком сложно. И кстати тогда появилось куча микроядерных проектов, но высокий порог вхождения - оставил их без разработчиков.
Hurd
И? Каковы итоги?
L4. Лайнокс можно оставить на какое-то время, как рантайм
И почему же дипломированный аноним до сих пор не утёр "студенту-недоучке" нос?> тогда появилось куча микроядерных проектов, но высокий порог вхождения - оставил их без разработчиков
И прекрасно. Уж лучше доступная людям несовершенная архитектура, чем совершенная, но понятная лишь одному академику.
Ну почему, возможно -- просто остаётся академическими упражнениями обычно.При попытке выйти в реальный мир вдруг внезапно чуточку оказывается, что комбинаторику неглупые люди описывали (и, может, даже преподавали прослушавшим курс).
Потом бегают юные бздишники-джависты-велосипедисты и рассказывают всем про настоящиеъ серебряные пули :)
Хорошо. Назови мне грамотно спроектированное опенсоурс5ое решение. И желательно - чтоб изначально оно не было закрытыми исходниками, которые отдали в опенсорц.
Postfix, nginx, PostgreSQL, Hadoop, почти всё связанное с кластерами.
И где в этом списке грамотно спроектированные продукты?
Ну и сиди на apache
STL Степанова и Ли.
Моя ты лапочка, что же с тобой сделали
Так Линус же всегда сам говорил, что: "микроядро лучше чем его монолит. но монолитный линукс уже готов, а ваш юникс ещё на горизонте".Скорость разработки, как обычно.
ты вообще понятия не имеешь о чем говоришь.
В C++ есть модули. С разморозкой Вас
В GCC с адовыми костылями включаются, в QtCreator'е они не появятся никогда, в Visual Studio у них не работает IntelliSense. Не нужно рассказывать о том, что не будет юзаться ещё очень долгое время. Новые проекты будут писАться на чём угодно, но только уже не на плюсах. Плюсы -- это легаси, пора это принять.
Народ, для чего вы постоянно выделяете букву "а" в слове "писáться", как будто из контекста не понятно о чём идёт речь?
По той же причине, что и слово «бóльшее», где даже контекст не важен.
видел такое насчет "большая", а вот про "большее" как-то не встречал.
Формально есть, для галочки, но фактически хорошо, если к 2030 будет реально использоваться.1. Сейчас не все даже C++14/7 используют, не говоря уже о C++20.
2. Поддержка основными компиляторами всё еще частичная со звёздочками:
https://en.cppreference.com/w/cpp/compiler_support3. Пока большинство проектов перейдет на модули, пройдет очень много времени.
4. Навсегда останется легаси, которое этого не сделает.
GCC впереди планеты всей, а рядом шланг
А Линукс на C++ написан?
> А Линукс на C++ написан?Нет, но это не противоречит тому факту, что в C++ есть модули
Оно-то не противоречит, конечно. Только в контексте обсуждаемой новости - абсолютно бесполезное новшество для Линукса.
Моё ядро с подключаемыми в рантайме модулями передаёт вам привет. Так же, как и все dll-ки/so-шки. Или вы бредите идеей того, что в Си ничего нету и он не менялся с момента его создания? По такой логике питон — самый продвинутый ЯП, несмотря на то, что это просто навороченный калькулятор, у которого GIL — не баг, а фича, причём «невероятно полезная и крутая».
> Моё ядро с подключаемыми в рантайме модулями передаёт вам привет. Так же,
> как и все dll-ки/so-шки. Или вы бредите идеей того, что в
> Си ничего нету и он не менялся с момента его создания?Очередного опеннетного экспертуса не смущает, что модули могут быть на других ЯП. т.е. нахваливаемая им "модульность" - совершенно не на уровне языка, со всеми вытекающими проблемами оптимизации и вынужденными "костылями" вида LTO.
> По такой логике питон — самый продвинутый ЯП, несмотря на то, что это просто навороченный калькулятор, у которого GIL
Спрыги на унылую демагогию — самый продвинутый навых экспертусов, несмотря на то, что это просто бессмысленное и беспощадное сотрясание клавиатуры.
И с каких пор LTO стал костылём модульности
j96? дайте мне такую машину
-j96 ныне - это ещё так себе машина, всего лишь 48 ядер и 2 треда, какой-нибудь EPYC 7643, или дуалка из младших эпиков/тредрипперов.Ныне даже несервеный Threadripper 3995WX - это -j128 :D
А дуалка из эпиков может и -j256 оказаться.
А вы пробовали затестит стабильность бинарника на выходе 100500 ядер.Думаю что нет.
Если параллелизация на уровне Make, то со стабильностью ниче не будет (как повлияет на стабильность одновременная компиляция независимых исходников?). Реальные проблемы при сборке - это то, что сами Makefile-ы написаны отстойно, т.е. могут отсутствовать правила, указывающие правильную очередность сборки, в результате чего можно влет получить состояние гонки, когда с первой попытки не соберется, а со второй - вполне себе. Да и еще про закон Амдала забывать нельзя о теоретическом пределе ускорения при параллелизации.
Я просто поднял тему про которую никто особо здесь не говорит не более.Может я недоконца обозначил проблему и выразился точнее каюсь да.Это вопрос мы в компании изучали при разработке промышленного по и в том числе для космоса и как не странно проблема имела место быть.Это было исследование на предмет расспараллеливания кода при компиляции на 100500 процессоров и как это влияет на конечную стабильность работы программ после сборки и запуске на реальном оборудовании.Баги и странное поведение работы программ наблюдалось в итоге.А так да причины могут быть разные.Умничать все умеют в комментах а в реале героев которые ответят за упавший спутник связи из-за не понятных глюков софта не наблюдается чуть что бежать.Как помню фобос-грунт так и профукали где же вы были умные дяди минусаторы с форума чтож вы гении не приложили свой большой ум.
Тут нужно смотреть контекст. Спутники и ракеты - это дорого и жалко терять, поэтому софт для них должен быть математически(!) верифицирован. Линукс же и его стабильность особо не волнует в контексте того, что тебе просто нужна серверная ОС, которая будет крутить твой интернет-сервис. Поэтому ну ничего удивительного, что сделали статистический анализ зависимости количества багов от параллелизации и нашли корелляцию. Как бы правильно разрабатывать комплексные параллельные системы ОЧЕНЬ сложно. Тут как с управлением автомобилем - даже на небольшой скорости есть шанс погибнуть в ДТП, но при соблюдении ПДД, своевременном техническом обслуживании и использовании ремней (и рабочих подушках) этот шанс ощутимо снижается. Поэтому все пользуются автотранспортом, т.к. риски приемлемые.
>> Поэтому все пользуются автотранспортом, т.к. риски приемлемые.И боятся летать на самолетах, где реальный риск ниже...
>> на самолетах, где реальный риск нижеЗвездёж статистический
На км пути риск ниже
На поездку выше и сильно
Ну да, ну да. Именно поэтому, если происходит авария с каким-нибудь самолётом, об этом во всех новостях трубят. А информацию про автомобильные аварии приходится искать где-то в закромах сайта ГИБДД.Вот информация с сайта ГИБДД за 3 января 2022 года:
АВАРИЙНОСТЬ НА ДОРОГАХ РОССИИ ЗА 03.01.2022
ДТП 202
Погибли 30
Погибло детей 0
Ранены 316
Ранено детей 47И вот информация с сайта Межгосударственного Авиационного комитета за весь прошлый год (всего за год погибло 78 человек, не разбираюсь в моделях воздушных судов, но по-моему подавляющая часть аварий приходится на малую авиацию):
Дата Место происшествия Тип ВС Эксплуатант Ущерб
27.12.2021 в районе населенного пункта Азино Удмуртской Республики Ми-2RA-15671
АО "Казанское авиапредприятие"Погибших: 1 (данные уточняются)
ВС разрушено
10.12.2021 на границе Иркутской области и Республики Бурятия IAR-316RA-1881G
Частное лицоБез жертв
ВС разрушено
10.12.2021 на границе Кемеровской области и Республики Хакасия Robinson R66RA-07397
ООО "Кустард"Погибших: 1
ВС повреждено
25.11.2021 на удалении 26 км от н. п. Покачи (ХМАО) Ми-2RA-20406
АО "Авиакомпания Конверс Авиа"Без жертв (данные уточняются)
ВС уничтожено
03.11.2021 в районе аэродрома Иркутск Ан-12БКEW-518TI
ОАО «Авиакомпания Гродно»Погибших: 9
ВС разрушено
24.10.2021 в районе аэродрома Ватулино Московской области А-22ЮСRA-1242G
Частное лицоПогибших: 2
ВС уничтожено
17.10.2021 в районе озера Балхаш Алматинской области Республики Казахстан Cessna-182TRA-67213
Без жертв
ВС повреждено
03.10.2021 в районе н. п. Лыткарино Московской области Robinson R44RA-04172
Частное лицоПогибших: 3
ВС разрушено
22.09.2021 при облете радиотехнических средств аэродрома Хабаровск (Новый) Ан-26RA-26673
ЗАО «Летные проверки и системы»Погибших: 6 (данные уточняются)
ВС разрушено
16.09.2021 в районе озера Глубокое Советского района (ХМАО) Белый лебедьRA-1815G
Частное лицоПогибших: 2
ВС разрушено
13.09.2021 между селами Бехтеевка и Соколовка Прохоровского района Белгородской области ПЗЛ-101АRA-2388G
Частное лицоПогибших: 1
ВС уничтожено
12.09.2021 в районе посадочной площадки Казачинск (Иркутская область, Ленский район) Л-410RA-67042
ООО «Аэросервис»Погибших: 4 (данные уточняются)
ВС разрушено
23.08.2021 на посадочной площадке Ивановской ОКБ ANSATRA-20059
ООО АК «РусАвиа»Без жертв (данные уточняются)
ВС повреждено
23.08.2021 в районе н. п. Черкизово г. о. Коломна Московской области Borey BL010RA-3042G
Без жертв (данные уточняются)
ВС повреждено
12.08.2021 районе кордона Озерный Курильского озера (Камчатский край) Ми-8ТRA-24744
ООО АК "Витязь-Аэро"Погибших: 8
ВС разрушено
24.07.2021 в районе аэродрома Калинка Хабаровского края P-2002 SierraRA-2329G
Частное лицоПогибших: 2 (данные уточняются)
16.07.2021 в Бакчарском районе Томской области AN-28
RA-28728
ООО «СиЛА»Без жертв
Значительные повреждения ВС
08.07.2021 в районе аэропорта Толька (Ямало-Ненецкий АО) P2002-JFRA-01865
Нет данных
Значительные повреждения ВС
06.07.2021 в районе аэродрома Палана Ан-26Б-100RA-26085
АО «Камчатское авиационное предприятие»Погибших: 28
ВС уничтожено
30.06.2021 в р-не н.п. Лыткарино Московской области HARMONY LSARA-2086G
ОАО НПП «Звезда» им. ак. Г.И. Северина»Без жертв
Значительные повреждения ВС
27.06.2021 в районе горы Ай-Петри Республики Крым Robinson R44RA-04247
Без жертв
ВС повреждено
24.06.2021 РФ, Краснодарский край, Славянский район, 3.5 км западнее н. п. Забойский Ан-2RA-01430
ИП Заболотный Александр АлександровичБез жертв
ВС частично разрушено
24.06.2021 в районе населенного пункта Яренск Архангельской области Па-28 АрчерRA-2786G
Без жертв
ВС уничтожено
19.06.2021 в Суземском районе Брянской области СОЛОВЕЙRA-0598A
Частное лицоБез жертв
Значительные повреждения ВС
17.05.2021 в р-не острова Мудьюг Архангельской области Robinson R66RA-06358
Частное лицоПогибших: 1 (данные уточняются)
ВС разрушено
09.05.2021 в р-не н.п. Калейкино Альметьевского района Республики Татарстан ЕрмакRA-2994G
Частное лицоПогибших: 2
08.05.2021 РФ, Камчатский край, г. Петропавловск- Камчатский, в районе озера Синичкино Ми-2
RA-15715
АО «Озерновский РКЗ № 55»Погибших: 2
ВС уничтожено
23.04.2021 РФ, Иркутская область, Черемховский район, 1.5 км юго-восточнее н. п. Рысево N-65RA-2722G
Частное лицоПогибших: 2
ВС разрушено
17.04.2021 в районе населенного пункта Ильский Краснодарского края Ми-2RA-20977
ООО «МАЛ-АВИА»Погибших: 1 (данные уточняются)
ВС разрушено
23.02.2021 в р-не п.п. "Песь" Новгородской области Robinson R66RA-06201
ООО "Авиакомпания "Баркол"Без жертв
Значительные повреждения ВС
08.01.2021 Россия, Ленинградская область, Ломоносовский район, район посадочной площадки Гостилицы РОККИRA-2659G
Частное лицоПогибших: 3
ВС разрушено
> но по-моему подавляющая часть аварий приходится на малую авиациюТам даже не малая, а частная. в основном 2-х местные пропеллерные или вертолёты типа Робинсон.
Лицензию на Робинсон можно получить за 3 месяца. На нормального пилота, минимум, 6 лет учатся!
Допуск к полетам через 10 лет, из них лет 5 пролетаешь как второй пилот.
На http://vz.ru бывают сообщения и по авиа-, и по авто-, и по железнодорожным да судоходным катастрофам и крупным инцидентам -- если "Ваше" СМИ отличается в этом плане избирательностью, подумайте, за кого оно Вас держит.Лично я до сих пор знаю только убитых и покалеченных в результате автокатастроф -- думаю, в том числе по причине гораздо более низкого порога вхождения и приличных шансов за первые же два года, почуйствовав себя "уже мастером", уже натворить бед.
(впрочем, make -j тут вроде бы напрямую ни при чём)
> На http://vz.ru бывают сообщения и по авиа-, и по авто-, и по
> железнодорожным да судоходным катастрофам и крупным инцидентам -- если "Ваше" СМИ
> отличается в этом плане избирательностью, подумайте, за кого оно Вас держит.О том и речь, что автомобильные аварии случаются гораздо чаще и интересуют СМИ лишь в исключительных случаях. Если они о каждой автомобильной аварии будут писать, то остальные новости в них растворятся.
> Лично я до сих пор знаю только убитых и покалеченных в результате
> автокатастроф -- думаю, в том числе по причине гораздо более низкого
> порога вхождения и приличных шансов за первые же два года, почуйствовав
> себя "уже мастером", уже натворить бед.Именно.
> (впрочем, make -j тут вроде бы напрямую ни при чём)
Емм, что вы там собираете? А ниче такого, что нормальные компиляторы выдают одинаковый разультат(побитово) в бинарниках?
> Емм, что вы там собираете? А ниче такого, что нормальные компиляторы выдают
> одинаковый разультат(побитово) в бинарниках?Ну ты сам-то понял, что это коммент полного лoxа?
Я тоже некоторое время поработал в шаражке запускающей спутники(внезапно даже успешно). Сильная бюрократия, слабая квалификация и бесконечноеь чинопочитание преобладающее над знаниями и умениями были на каждом шагу. В основном там работали либо маразматики 80+ лет, либо просиживатели штанов, либо студенты для строчки в трудовой. Толковые специалисты там не задерживались.
Так что близость к спутникам, военной приемке и госаппарату в целом это скорее приговор чем повод для повышения авторитета.
> Баги и странное поведение работы программ наблюдалось в итоге.Что-то где-то запустили, после чего-то что-то стало не работать почему-то. Никакой конкретики, которой можно было бы ожидать.
> недоконца
> как не странно
> не понятныхЧадо, у тебя не "в компеляторе" проблема (и даже не в тех рукожопах, которые так систему сборки умудрились написать, что получили невоспроизводимый результат для, скорее всего, теми же конечностями писаных исподников).
А в тройке по русскому для начала, если по-честному. И натянутой тройке -- по математике.
Не кивай на других. Не обобщай с умным видом того, в чём вообще не соображаешь.
Начни с себя.
А там и космос вытянем заново, и не только его.
> Может я недоконца обозначил проблемуОпределённо.
> Это было исследование на предмет расспараллеливания кода при компиляции на 100500 процессоров и как это влияет на конечную стабильность работы программ после сборки и запуске на реальном оборудовании.
Вот тут как раз было бы очень интересно увидеть ссылку на это исследование. Реально любопытна методология исследования, особенно та часть, которая описывает выборку, на которой проводилось исследование. Но ещё более интересен список идентифицированных причин таких багов, потому как это явно грабли, которые неплохо было бы уметь перешагивать.
Может это был distcc? Да, там бывают свои приколы
> Если параллелизация на уровне Make, то со стабильностью ниче не будет (как
> повлияет на стабильность одновременная компиляция независимых исходников?).LTO, не, не слышал?
Линковка a+b+c+d, это не тоже самое что (a+b) + (c+d) ... и вообще разное (a+d) + (b+c)
> Реальные проблемы при сборке - это то, что сами Makefile-ы написаны отстойно,
> т.е. могут отсутствовать правила, указывающие правильную очередность сборки, в результате
> чего можно влет получить состояние гонки,Сцк, откуда вы все повыползали??!!! С онлайн курсов чтоль?
Race condition - это борьба за общий ресурс, make - это линейная приблуда.
-j n - это тупа n форков со своими линейными списками.> когда с первой попытки не соберется, а со второй - вполне себе.
>> Если параллелизация на уровне Make, то со стабильностью ниче не будет (как
>> повлияет на стабильность одновременная компиляция независимых исходников?).
> LTO, не, не слышал?Ставлю навскидку тыщу рублей, что описанное в #74 было без -flto со товарищи :)
> Линковка a+b+c+d, это не тоже самое что (a+b) + (c+d) ... и вообще разное (a+d) + (b+c)Как эт ты их так сгруппировал? Я так не умею, у меня линковщик все файлы разом хочет получить. Причём make ему даже аргументы всегда в одном и том порядке подставляет независимо от -j.
Рейс кондишн в мейкфайле - это когда есть фактическое happens-before отношение между множеством исходников X и Y по коду, и эти X и Y собираются в разных makefile-таргетах. И при этом нет явного указания в мейкфайле, что один таргет является зависимостью другого. Господин павлин(-ункс), кто ж с тобой спорит-то, что race conditition - это борьба за общий ресурс. Здесь общий ресурс - каталог build/output, откуда все таргеты используют выхлоп друг друга. Если раньше отработает неявный дочерний таргет и положит результат в build/output, то все ок - неявный родительский таргет обнаружит что надо и успешно соберется. А если не повезет и раньше начнет работу родительский и компилятор не обнаружит чего хотел - сборка свалится.
Приведи пример зависимости сборки объектника от другого объектника.
Это заблуждение часто наблюдается у программеров-прикладников, которые рейсом называют всё, что то работает, то нет. Слово-паразит.
А что там на стабильность-то влияет?
Собираются файлы всё равно независимо, между зависимостями сборка притормаживает.
Финальный выхлоп делает ld, ему как-то на количество ядер фиолетово.
А известно ли, какая машина у тестирующего?
Когда я занимался правками ядра, нам выдавали простенькие атлончики. И инкремент шёл 5 минут. И можно было идти гулять.
Торвальдс же, недавно рекомендовал amd 3970x. Как базовую машину.
Но тут что-то мощнее.
И что вы с ней будете делать.Оплачивать счета за электроэнергию?
> j96? дайте мне такую машинуВ наши дни такие машины – абсолютная норма, особенно если ты серьезный разработчик, а не веб макака. Очнитесь уже со своими core 2 duo и добро пожаловать в этот дивный новый мир.
Расшарь-ка мне пару сотен своих ядер. Раз у тебя там мир такой новый и дивный.
amazon EC2 вам в помощь - не благодарите
>Очнитесь уже со своими core 2 duo и добро пожаловать в этот дивный новый мир.Ты чо, как так можно? У вас там страшные штеуд МЕ, уефи и другие непонятные аббревиатуры
> Ты чо, как так можно? У вас там страшные штеуд МЕ, уефи
> и другие непонятные аббревиатурыОтдельная PCI сетевуха спасёт отца русской демократии.
> j96? дайте мне такую машинуВ наше время пользователь core 2 duo - это человек пожилого возраста или бухгалтер в не прибыльной конторе. Для большинства же пользователей двух\четырёх ядерные системы окончательно умерли в период 2015-2017 годов, оставив лишь нотки ностальгии.
>j96? дайте мне такую машину2 шт. Baikal-S
Таненбаум был прав
Всегда был, все это знают. Вот вам голая правда о поделии аутиста Линуса.
А чё минусуют? Всё правильно сказал. Этот Трольвадс тот ещё баран упёртый! Послушал бы "старших товарищей" - сейчас бы в ядре было 20 файлов, а всё остальное спокойно И НЕЗАВИСИМО жило в отдельных мирах.
Короче, баранолинукс достиг стадии, когда понятно, что ишак сдохнет, но пытаются проехать лишние 100 метров.
Похоже. что в Гугле уже это поняли, причём несколько лет назад, и уже серьёзно пилять Фуксию на замену.
Фуксия они полят ради того чтобы иметь свою коммерческую Ось. Архитектура не причём.
> не причёмсхоронил
Да обсохраняйся. Symbian и QNX/BBerryOS показывают, что в условиях приближенных к реальной жизни, микроядро почему-то не взлетает. Хотя концепция, конечно, красивая.
Самое смешное - фактически к этой концепции всё и пришло! На серверах крутятся микроядерные гипервизоры, в которых на правах сервисов живую виртуалки и контейнеры. Запуск и умирание которых не приводит к падению базового гипервизора.
Ждём ядро без фатальных недостатков от Gogi на 20 файлов.
Не зря яблоОС пошла по пути микроядерности, являясь де-факто самой надёжной осью. Хотя, конечно, играет фактор того, что и железо и ось пилит одна компания, в отличии от зоопарка ПК железа.
Там гибрид.
Еблёс - шматки Mach 3, никакого там микроядра не осталось
Оно и видно что смузихлёб. Всё правильно сказали - нет в огрызкоси никакой микроядерности.
Безусловно. Ведь он профессор, а Линус студент. Концептуально MINIX очень крутая ОС. А Linux превращается в Вавилонскую башню.
Ну и где его minix теперь? Ты им сам-то хотя бы пользуешься?
minix everywhere - intel me :D
Официально Таненбаум негодует
много где - просто тебе об этом не будут сообщать.
"У нас есть такие приборы - но только мы их не покажем" серия 100500-я. Суровое академическое BSD-строение во всей красе.
> "У нас есть такие приборы - но только мы их не покажем"
> серия 100500-я. Суровое академическое BSD-строение во всей красе.С разморозкай - для SaaS, в котором сейчас заколачивают миллиарды, что GPLv2/3, что BSD - совершенно без разницы. У Гугеля вон, еще 14 лет назад был стабильный и улучшенный EXT2 и кажись, планировщик, но ...
Мне непонятно как они вообще всё это мержат? Он год назад делал срез, за этот год ещё куча кода, новых заголовочных файлов и т.п.Очень интересно как они в состоянии с этим совладать?
git rebase постоянный
Ща те каргокультисты скажут, что рибэйз - это зло 🤭
Rebase -- наше фсё. А зло это merge.
Костыль для любителей линейной истории.
Merge комиты выглядят уродливо. Какие у merge стратегии преимущества перед rebase?
Моё дело -- вбросить. А дальше вы уж как-нибудь сами.
Давно ли они стали альтернативой друг другу?
Да, всегда были
С мердж комитами прикольно. Иногда надо покупать парочку пузырей водяры, звать пацанов что бы разобраться как и куда идут эти сраные ветки. С линейной историей поводов с пацанами собратся будет меньше :(
Ребейз это переписывание истории, то есть вместо одно коммита создаёт на его основе новый коммит, который не тоже самое. Если автор взглянет на свой коммит после ребейза, он его не узнает. Коммит будет отличатся от того чтобы было задумано, но будет сформирован автоматически, от чего может возникнуть ошибка там где её никто не ждал. А уж о проблеме что это полностью портит работу остальных, кто ответвился до ребейза и говорить не стоит.
1) Если конфликты при ребейзе, то они будут и при мердже и всё равно придется аккуратно разбираться, чтобы ничего не потерять.
2) Для ребейза есть один строгий шаблон, когда он уместен - 1 разработчик работает строго в фича-ветке своей задачи и делает ребейз ТОЛЬКО с релизной/мастер веткой, перезаписывая коммиты в своей origin/feature ветке через легальный(!) пушфорс. Адекватные люди никогда не делают ребейз, если в одну ветку коммитят несколько разрабов - оно не для этого флоу было придумано.
В Солярке такая же беда.
В случае солярки это проблема вида "цветки на могилке слишком быстро вянут".
Не факт что расспаралеливание кода на ядрах процессора приносит улучшенную стабильность бинарника на выходе.Сами разработчики GCC рекомендуют иногда компилировать в один или два потока.Так что новость актуальна.Можно компилить теперь в один поток быстрее.У кого эпики или 100500 ядер профита не получат вообще.
Какая ещё стабильность бинарника, деточка? Иди уроки делай. И запомни, что распараллеливание сборок на конечный ре0зультат не влияет. Но не всегда оправданно, потому что рано или поздно бутылочным горлышком окажется io.
Деточка это вы почитайте доки gcc и gentoo потом пишите.А еще поинтересуйтесь как разрабатывается код под процессоры для орбитальных спутников и космических зондов.Да ракеты забыл извините деточка.
И сейсас ты такой — хопа! — вывалил ссылки на нужные места доки gcc и gentoo и рассказал тру стори, как разрабатывал код для спутников, какие нашёл грабли, и в чём была их причина.
Эх, что-то размечтался я…
Это секретная информация.Государственная тайна.Вам деточка этого никто не раскажет.Так что товарищ майор иди ищи дураков и делай себе карьеру в другом месте а здесь на форуме приличные люди программисты.
>нужные места доки gcc и gentooЭто гостайна? :)))
В нужных местах можно узнать всё, а всё - гостайна, значит и нужные места тоже
Уважаемый, какая "параллельная" компиляция на GCC? Каждый отдельный unit of compilation собирается в 1 поток (потому что при добавлении параллелизма теряется sequential context и из-за этого теряется возможность многих важных оптимизаций). Там только в 2020 году на Google Summer of Code был хакатоновский проект по добавлению параллелизации в сборку отдельного юнита, который до сих пор в стадии proof-of-concept. Сейчас параллелизация происходит только на уровне Make-файлов, когда независимые рецепты собираются одновременно.
Все баги, которые лезут при параллельной сборке, происходят из-за криво написанных Make-файлов или из-за состояний гонки внутри самой утилиты make.
Если нестабильность на уровне сборки - надо заводить багу.
Искать повторяемость ошибки.
Потом локализовывать место возникновения.
И затем исправлять.
Исправлять какие ошибки не сложно. Так как можно закрыть ошибку меньше, чем за неделю.Главное не плодить правила сборки.
И не искать виновных.
Толка чуть. Не Боги горшки лепят. Все ошибаются.
И исправить можно.
Какой умный мальчик. Ящик печенья и банку варенья герою.
Проблема глубже, чем воспитала юных хакеров современная система: компилируется - значит работает.
Всегда есть сложновоспроизводимые проблемы из-за гонок, отсутствия необходимого железа, реверс-инжиниринга для поддержки проприетарного железа или наличие крикливых индусов с LGBT+ поддержкой. Из-за этого поддержка кода превращается в кривой спаггеттинг, вносятся изменения в зависимости от каждой платформы или вносятся противоречивые правки через дефайны, которые очередным индусом-оптимизатором приводятся к неработающему коду.
Ты пьян, обдолбан или просто шизофреник?
Нет, он просто говорит правду. А такие как ты ее никогда не слышали или не желают слушать. Вас воспитала та самая система.
Что ты несешь? 1. Причем тут вообще расспаралеливание 2. На уровне make это ни как не влияет на сами бинарники
> улучшенную стабильность бинарникаЧто Вы несёте?
ну он медленнее распадается и гниёт. период полураспада опять же увеличивается.
Быдлокод на сях - это быдлокод в квадрате. Побочный эффект от того, что заголовочные файлы просто тупо инклудятся друг в друга, так что небольшой с виду код может в итоге оказаться для компилятора просто гигантским. Ну и перекомпиляция одного и того же по 100500 раз. Проблема решена в делфях, где юниты компилятся отдельно. Это делает компиляцию почти мгновенной. Но есть проблема. Перекресные ссылки невозможны. И это немного противоречит логике. Т.к. то, что можно реализовать внутри одного модуля, почему то нельзя реализовать, если просто для красоты разделить программу на два. Приходится танцевать с бубном. Но такая вот специфика. За скорость нужно платить.
Так ведь Delfi вроде мертв.Не?
Он мертв не поэтому. А потому, что кто то хочет овердофига бабла за лицензию. А лазарус, как и любая другая слоупочная опенсурцная муть, развивается крайне медленно. По релизу (условно) в год с мелкими исправлениями. Иногда мне кажется, что эти опенсурцеры просто в игрульки играются. Мол у нас есть проектик. Мы с ним играемся. Но у нас по сути нет ни одного человека, который мог бы реализовать что то реально стоящее. А потому мы раз в год прикрутим какой нибудь маленький фикс совместимости с делфи.
>> Но у нас по сути нет ни одного человека, который мог бы реализовать что то реально стоящее.Кто тебе мешает стать этим самым человеком?
Обычно это лапки...
Double Commander. Вполне солидный проект.
>> Но есть проблема. Перекресные ссылки невозможныОчень даже возможны. Попробуйте часть ссылок в "interface", а остальные в "implementation"
Идеальное прикрытие для внесения бэкдоров.
Это русский?
Инго-то Мельниченко?
Не, куда там.
Но мужик грамотный.
Если примут, то это на 6.0 уже потянет
Примут примут обязательно ждемс с нетерпением.
Про Rust Уже вспомнили ?
вспомнили что не нужен
Разве что таким неосиляторам, вроде тебя.
я начинал учить раст, очень его хвалили, но умер от потери крови, вся из глаз вытекла от синтаксиса. пишу с того света
> я начинал учить раст, очень его хвалили, но умер от потери крови,
> вся из глаз вытекла от синтаксиса. пишу с того светаМожет к окулисту сходишь для начала? Обычно, люди склонны винить всех вокруг в своих бедах, только не себя.
Зачем о нем вспоминать если это было сделано по-человечески еще в делфях задолго до раста?
Хотя у него с модульностью тоже все прекрасно. Вообще сложно представить хоть что-то, где модульность будет хуже чем в си.
> Зачем о нем вспоминать если это было сделано по-человечески еще в делфях задолго до раста?Delphi не бесплатны. Rust - бесплатен. Хотя бы поэтому. У Rust удобней инфраструктура (ИМХО). Rust поддерживают MS, Google, Mozilla, Huawei. Delphi - только Borland, которая уже далеко не торт.
>У Rust удобней инфраструктура (ИМХО).Тоже программироуешь браузеры?
Rust не только для браузеров подходит.
Что? Зачем?
Проблема в том, что с точки зрения функциональности, стабильности, надёжности, безопасности и скорости работы эти патчи ничего не улучшают. Для пользователей эти патчи ничего не добавляют, но при таком объёме изменений возникновение функциональных регрессий почти неизбежно, а эти регрессии уже могут влиять на качество работы ядра, а не только на удобство его сборки.
Совершенно верно вот и надо будет больше тестов а потом как всегда патчи патчи и еще раз патчи.Энтропия вселенной однако.
Как практик, могу сказать, что после повышения времени сборки 3 минут - ошибки начинают возникать просто из-за вынужденной смены контекста при ручной проверке
Патчи приводят кодовую базу в порядок. Из-за свободы, которую даёт разделяемая сборка в С и С++, разработчикам часто сносит голову, и они начинают включать заголовки не глядя, создавая бардак из перекрестных включений. Что не только существенно замедляет скорость сборки, но ещё затрудняет понимание структуры кода человеком, а также приводит к незаметным ошибкам связанным с порядком обработки препропроцессором объявлений-макросов.
В С++ уже приняли modules, которые в перспективе могут улучшить ситуацию. А вот в С остаётся уповать только на разработчиков. Но люди - это всегда слабое звено: они невнимательны, глупы и ленивы.
> разработчикам часто сносит голову, и они начинают включать заголовки не глядя, создавая бардак из перекрестных включений.но ты, конечно, не из их числа, зато аналитика у тебя уровня 80
Так ты плати за рефакторинг и проблем не будет. Аааа...не хочешь? Ну тогда терпи.
в линуксе заголовочные файлы адский ад, тут включи дефайны gnu, там bsd и смотри не перепутай, соберётся, но с ошибками в процессе работы.
Линукс написан на Си. Там НЕ БУДЕТ Си++. Поэтому появившаяся в этом языке модульность ничего не изменит. Шанс есть только у Rust пока что.
Как бэкенд разработчик в ентерпрайз проекте на 3 млн строк кода, выражу мнение, что без чисто технического рефакторинга, который ничего продуктового не добавляет, а только уменьшает техдолг тяп-ляпных архитектурных решений, проект со временем становится невозможно сопровождать. В каждой большой компании есть правило, что N процентов спринта команды отводится на ликвидацию имеющегося техдолга.
> Для пользователей эти патчи ничего не добавляютЕсли маме освободить больше времени (скажем, купив стиралку или посудомойку) -- может статься, ей получится уделить больше времени сынишке. Как-то так и тут.
Причём со сборками теми же есть эффект потери/сохранения контекста: пока что-то происходит достаточно долго (минутку или пять -- всяко дольше тех секунд двадцати, которые ты лично его согласен обождать без переключения на другое), протерять собранный в голове контекст или его нюансы несколько проще, чем когда make\n -- размял плечи, шею, посмотрел вдаль в окошко, о -- а вот и результат готов.
С другой стороны, если прерывания по делу идут слишком часто, тоже бывает нехорошо (в сторону выжатого лимона и в клиническом случае -- выгорания). В этом плане опять вспоминаются http://lib.ru/MEMUARY/ERSHOW_W/zapiski_ezdowogo_psa.txt насчёт различия полётов на Ил-18 и Ту-154 с точки зрения количества рейсов в сутки...
Однако в реальности после обретения стиралки эта мама будет либо больше залипать в сериалы, либо сможет лишние пару раз вымыть полы или протереть пыль.
Так люди устроены.
Эти регрессии будут способствовать на порядки большей прогрессии
"с 15.5 до 27.7 сборок в час" ниочом же, мой монитор 144fps. Я хочу 1 сборку на каждый фрейм. Играть в линукс на ~30fps это слайдшоу. Жду новые райзены TR с DDR5.
Путаешь частоту обновлений с частотой кадров.
Он часы с секундами путает (и fps с bph), если что... но типа смешно.
Забуферизируй каждую сборку и выплюни её в 144 кадра, когда всё случится. А чё, сейчас пинг с карты в 20 мс — это норма, народу нравится.
А вы запустите сборку ядра с высокой говорливостью, будет не успевать выводить в терминал, при должной оптимизации, возможно, упретесь в 144 FPS, были же новости про GPU-ускорение для отрисовки текста в терминалах, над ними смеялись, а вот оно и пригодится.
Чую нас ждёт год оптимизаций. Будет круто, если эти патчи примут в этом году. К концу года Python ускорят. Явно будет ещё что-то.
Вот бы ещё пайтоновцы немного на другие, особенно мобильные, архитектуры хоть иногда смотрели и собирали либы и под них, цены бы им не было
> К концу года Python ускорят.Скажи ещё, GIL выпилят.
Не выпилят, но сделают возможность в одном процессе спаунить subinterpreters. Это можно и сейчас уже в 3.10, но сейчас подинтерпретаторы шарят GIL. А в 3.11 обещают сделать, чтобы каждый subinterpreter имел свой собственный GIL. Если это сделают - то ты сможешь делать в одном процессе сколько угодно независимых объектов-интерпретаторов, не шарящих общий GIL, глобальный для процесса. А значит ты сможешь в мультитрединг с закэнселленым GIL.
Питоновцы изобретают Веб-Воркеры.
Питоновцы могут запускать ивент лупы программно, прикинь! Надеюсь с пальмы не упал?
...и вся эта помойка развивалась под неусыпным наблюдением главного Пингвинукса-трольвадса... он что, вообще ни в зуб ногой в Си? Неужели городить помойку годами не вызывало у него хотя бы инженерного чувства брезгливости? Тоже мне, "революционер"!
Гоги вы чьих будете? За Паскаль топите.
Вы бы патчи ему кидали, а не гнали на человека лишний раз. Он написал ядро и дожил до 2022, всё ещё находясь в статусе его мейнтейнера. Пора ли деду на пенсию или нет — вопрос субъективный, но факт в том, что содержать такую большую помойку из кода, который работает и работает великолепно в 99% случаев — это как минимум достойно уважения.
> на стадии постпрепроцессингаЧто за дебильный язык, в котором нужна фаза пост-пре-процессинга???
гbI-гbI :) Добро пожаловать в 70-ые! Время _килобайтной_ памяти и самых маразматических решений в ИТ!
Каждый язык развивался в меру шизанутости авторов (привет, ЛИСП!) и потому ТОГДА это никого не удивляло и не вызывало инженерных споров. Сегодня Си - самое маразматичное, что можно использовать для разработки.
Сегодня это любой язык, Сишечка просто не прячет этапы и позволяет исполнять их раздельно. Маразматично выбирать язык по принципу лишь бы хайповым был, на сегодня у си нет альтернатив по качеству и эффективности батареек и нет никаких предпосылок к изменению ситуации. Я даже не вижу что через 30 лет какой-нибудь язык мог бы сравняться с сишечкой, может быть плюсы лет через 100 догонят.
Сегодня у си нет альтернатив по количеству рукожопства с памятью, выходов за границы массива и переполнений буфера (и тысяч cve как результат). С ним может поспорить только с++ в проектах, для погромистов которых это всего лишь "си с классами" и они не используют правильное RAII ради мнимой производительности, а таких еще очень много.
Хотя бы быстро компилируется и работает. Современные инструменты позволяют избегать большинства ошибок. Статистически все эти переполнения случаются в 1 из миллионов случаев применения адресной арифметики, что не так и плохо. Критические ошибки с перепутанными знаком, порядком аргументов, или прочее подобное случаются куда чаще и в любом языке, и от них нет никакой защиты.
От перепутанного знака могут помочь юнит-тесты, от неправильной бизнес-логики - интеграционные.
А от выхода за границы массива при неудачных входных параметрах - даже фаззи-тестинг помогает в единичных случаях. Так что мимо.
Почему тогда не помогают?
Потому, что теоретизировать - это вам не код писать.
> нет альтернатив по количеству рукожопства с памятью, выходов за границы массива и переполнений буфераУ тех, кто прогуливал в школе арифметику и не умеет складывать-вычитать целые числа.
Не, ну зачем вы так про разрабов ядра linux, openssl, xorg, firefox и сотен других.
Они вполне неплохие люди и программеры, не нужно их так обижать. Но раз в год они себе стреляют в ногу, а иногда оно ее отрывает по самую Ж, причем не только им, но и миллионам благодарных юзеров.
Дело тут скорее в сложности продуктов. Да и на "безопасных" языках что-то не спешат пилить альтернативы (они ещё и конкурентоспособными должны быть при этом). Всех достижений "мы переписали очередной приветмир на додиез".
Пилят потихоньку. Просто достаточной массы разработчиков не набралось пока.
И не наберётся. То ж не формы на венде клепать, тут думать надо.
Судя по опросам StackOverflow - процесс пошёл. А ты и дальше можешь продолжать "думать", что спрятав голову в песок аки страус, избежишь прогресса.
> ...Да и на "безопасных" языках что-то не спешат пилить альтернативы ...Тут все не так просто и с Си, и с "безопасными" языками... Ведь процессор ну абсолютно ничего не знает о массивах, строках, буферах и других структурах (в том числе и указателях), которыми оперируют языки высокого уровня. у процессора есть адреса ячеек памяти в регистрах - это все, что он может и "понимает". Да, на Си можно написать код, который будет вести себя подобно "безопасным" языкам, но, как и в этих "безопасных" языках это будет не "бесплатно" - требует определенного процессорного времени на проверки выхода за пределы высокоуровневых структур данных. Магии НЕ СУЩЕСТВУЕТ в нашем мире! "Безопасные" языки используют точно такие же низкоуровневые команды процессора, что и Си, и даже Асм, которые работают с адресами ячеек памяти или с регистрами (но в них данные нужно загрузить из тех же ячеек памяти с их адресами или выгрузить в нужные ячейки памяти по адресам) - других команд у процессора просто нету. Просто на каждый чих эти языки тем или другим способом автоматически добавляют пачку проверок в runtime - ведь на этапе компиляции не все адреса извесны. Никто не запрещает аналогично поступать на Си и на Асме. НО! При этом растет "служебная" нагрузка на процессор (на проверки всех границ и условий) - программа работает медленнее. Да, я знаю, что мне сейчас тут набросают примеров программ на Си и на $SAFE_LANG, когда на Си медленнее - но тут необходимо детально разбирать алгоритмы и код. При использовании одинаковых алгоритмов и оптимального их кодирования на Си будет быстрее - за счет отсутствия принудительных проверок на каждый чих. А обратный результат вероятнее всего говорит либо о разных алгоритмах (для программы на Си менее оптимизированный) либо о неоптимальном кодировании алгоритма на Си. Да, я знаю про Паскаль, Модулу и Оберон - но там та же петрушка, иначе это никак реализовать на современных архитектурах процессоров невозможно. Даже Java-процессоры не оперируют высокоуровневыми структурами данных.
> Магии НЕ СУЩЕСТВУЕТ в нашем мире!Дай я пожму твою руку!
> У тех, кто прогуливал в школе арифметику и не умеет складывать-вычитать целые числа.Как хорошо, что в России таких негров можно называть неграми.
У вас логическая ошибка в высказывании (безотносительно к расистской сути такового): не все негры безграмотны, и не все безграмотные - негры. Причём здесь Россия, кстати? В ней негры живут, что ли?
Согласимся. По факту это так. Заменить Си нечем :-(. Какой бы он ни был, остальное прочащее на егг замену ещё хуже.
Rust. Вполне адекватная замена.
В "замене" двусвязный список без unsafe уже осилили, или как обычно "не работает - не нужно"? Платформы, отличные от попсового x86 осилили, или как обычно? Сборку стандартной библиотеки без gc осилили или как обычно?
> Сборку стандартной библиотеки без gc осилили или как обычно?Опеннетовске Воены Антирастового Сопротивления непутание методичек осилили или как обычно?
Когда крыть нечем, но что-то выcpать надо.
>>> Tier1 ... aarch64-unknown-linux-gnu
> Платформы, отличные от попсового x86...
>>> Rust does not use a garbage collector
> Сборку стандартной библиотеки без gc
> gc...
> Когда крыть нечем, но что-то выcpать надо.А ты самокритичный! Осознание - первый шаг к чему-то там, так держать! (На самом деле, мотивация твоих высеров разве что психологам интересна)
Добавят векторизацию на уровне языка, и ещё 100 лет будет не догнать
> Каждый язык развивался в меру шизанутости авторов (привет, ЛИСП!)Знаете, вот так взять и одной фразой расписаться в своей полной профнепригодности не каждый сумеет.
hint: sexp
Си это просто пхп своего времени. Даже хуже, у пхп вначале была эталонная реализация, а относительно нормальные альтернативы начали появляться с версии 5+.У си куча диалектов была с момента создания, куча несовместимых компиляторов, расширений.
Никто не думал об архитектуре, главное быстрее портировать юникс на очередной комп. Х*як-х*як и в прод. Первый стандарт появился только лет через 15 после создания языка, и то - они просто записали что уже было по факту.Плюс наяривание на обратную совместимость, из-за которого невозможно выкинуть всю каку, которая накопилась за эти 50 лет.
Поэтому и существует такая шизофазия как "постпрепроцессинг"
> У си куча диалектов была с момента создания, куча несовместимых компиляторов, расширений.
> Никто не думал об архитектуре, главное быстрее портировать юникс на очередной комп.MSVC видимо тоже юникс собирает. А остальные компиляторы, как ни странно, все поддерживают расширения из gcc.
> Плюс наяривание на обратную совместимость, из-за которого невозможно выкинуть всю каку,
> которая накопилась за эти 50 лет.Обратную совместимость винды, на которой ты сидишь, обратную совместимость x86 со своим предком из 70-х.
Что приятно, в Линуксе таки находятся адекватные люди! Сначала переделали файловый бардак и сделали Gobo-linux. Потом (когда до остальных слоупоков дойдёт) это станет мэйнстримом. Затем заголовочники поправят, пофиксив БАРДАК, который Линус разводил десятилетиями. Ну а потом уж дозреют и до перехода на Ди! Но это будет уже при наших внуках.
>переделали файловый бардак и сделали Gobo-linuxКак в Виндовсе?
>Ну а потом уж дозреют и до перехода на Ди! Но это будет уже при наших внуках.
Гоги топит за язык Ди.
Предлагаю Гоги сделать главным мейнтейнером языка Ди (хотя почему Гоги не предложит написать линукс на Porth или другом, например своём самопальном языке — не понятно). Предлагаю проект назвать соответствующе: "Дикс". А что, звучит!
За 15 лет не написано ничего известного, у раста куда больше шансов получить распространённость (not to mention раст, в отличие от д, не завязан на рантайм с гц).ПС. гоболинукс -- помойка.
Шансы равны и равны 0
Обе поделки поделаны чтоб быть и не несут никаких новых концепций
Маркентинговое оно
Сахарок приятный в принципе.
>Обе поделки поделаны чтоб бытьНе чтобы быть, а чтобы избавиться от тех годами копимых "наработок" на Си, Си ++.
Вот один попытался расчистить эти авгиевы конюшни, и пока непонятно, к чему это может привести. А можно было сразу на нормальном языке с нормальной инфраструктурой писать, и вот этого вот труда Сизифа избежать. Но разве ж это можно луддитам объяснить...
>на нормальном языке с нормальной инфраструктуройНа го нельзя писать системный софт. Можно, если очень хочется, но нельзя. О многих вещах можно сразу забыть.
Думаю, предыдущий высказывающийся имел ввиду Rust, а не Go.
Но ведь то, что он сказал, явно не про руст с его нпм. И в его нпм нет ничего примечательного. А в самом языке нет ничего инновационного или уникального, всё выглядит как костыли для жс-обезьян. Нет готовых батареек, наконец, а те, что есть, работают ощутимо хуже плюсов.
> руст с его нпмЧего?
Ржавая версия NPM. Как pip в питоне.
cargo в Rust куда как функциональней, чем pip в Python.
У Rust нет NPM. Ты его с чем-то другим попутал.В самом языке есть:
- строгая типизация (в C такого нет);
- умные указатели (в C такого нет);
- контроль висячих ссылок (в C такого нет);
- контроль выхода за пределы границ массивов (в C такого нет);
- родные макросы (часть языка, в C такого нет);
- модульность (в C такого нет, в C++ появилась недавно, но пока только на уровне стандарта без должной поддержки со стороны компиляторов (как утверждают другие участники форума));
- относительная простота освоения (по сравнению с C++);
- оптимальный по производительности код на выходе компилятора (такой же быстрый и небольшой по размеру, как у C).При этом в Rust нет:
- ситуаций UB, как в C++ (сплошь и рядом);
- GC (как в Go);
- объектно-ориентированного программирования, вместо него используется куда лучший с точки зрения лёгкости чтения и последующего сопровождения кода принцип композиции (изучение многоуровневой иерархии объектов в ООП да ещё с множественным наследованием - то ещё "удовольствие").Плюс инфраструктура в виде стандартных crates.io, cargo, форматтера кода, линтера.
В первом предложении ты утверждаешь, что нет нпм, потом льёшь список воды, и завершаешь тем, что он самый хороший, потому что у него есть нпм. Что-то тут не так.
У Rust нет NPM. Или ты централизованную систему пакетов имел ввиду? Если да, то впредь выражайся яснее, если хочешь, чтобы тебя понимали.> он самый хороший, потому что
Он самый хороший потому что - перечитай список ещё раз, почему именно, если с первого раза не дошло. Хотя разжую, пожалуй. Централизованное хранилище пакетов ОДНО ИЗ МНОГИХ преимуществ, а не ЕДИНСТВЕННОЕ.
> Что-то тут не так.
У тебя проблемы с логическим мышлением. Вот что.
Не систему пакетов, а доверие вендору и к тому, что в гнилой помойке нет и не будет малвари. Это один из основных недостатков. Дальше не читал, уж извини, ничего полезного ты сообщить не способен.
> Дальше не читалЯсно, чукча не читатель. :)
> Это один из основных недостатков.
И снова проблемы с логикой.
Если ты находишь код (библиотеку) на каком-то стороннем сайте (вместо централизованного хранилища), у тебя точно так же нет никакой гарантии, что там не будет мэлвари, как и в случае с централизованным хранилищем. Но тебе, кроме такого отсутствия гарантии, приходится ещё шариться по Инету, тратя на поиски дополнительное время.
В серьёзном бизнесе не доверяют никаким хранилищам (если только поставщик мамой не поклялся и не отвечает деньгами, да) и проверяют все зависимости прежде, чем привязаться к верифицированному коммиту в системе контроля версий. Для всех используемых пакетов. А на доверии, это всё уровень нмп-помойки и её обезьян, экономящих время, и то, что её активно навязывают (карго), никак не может быть достоинством.
> В серьёзном бизнесе не доверяют никаким хранилищамНе доверяем - не пользуемся. Или кто-то заставляет? Вроде, простое решение, а поди ж ты, так долго разжёвывать надо.
> что её активно навязывают (карго)
Cargo - это не только загружатель пакетов извне. Это и система сборки, универсальная, стандартная, фичастая, ничем не уступающая, а местами превосходящаяя то, что есть в C, C++. Не нравится cargo - напишите свою, никто не запрещает. Не нравится crates.io - закройте к нему доступ.
> Cargo - это не только загружатель пакетов извне. Это и система сборки,
> универсальная, стандартная, фичастаяЯ вижу очередной npm, оно тоже "не просто загружатель, но и система сборки" и тоже "стандартное".
>> Cargo - это не только загружатель пакетов извне. Это и система сборки,
>> универсальная, стандартная, фичастая
> Я вижу очередной npm, оно тоже "не просто загружатель, но и система
> сборки" и тоже "стандартное".Куда-то не туда ты смотришь. npm - это менеджер пакетов - не совсем то же самое, что система сборки. Но допустим, что ты прав. Где такое же в стандартной поставке есть у C++ или C?
> При этом в Rust нет:
> - ситуаций UB, как в C++ (сплошь и рядом);Читаю:
> - прибит гвоздями к x86
> - объектно-ориентированного программированияСи, Ада
>> При этом в Rust нет:
>> - ситуаций UB, как в C++ (сплошь и рядом);
> Читаю:Не тем местом читаешь.
>> - прибит гвоздями к x86
И к ARM, и к MIPS, и к RISC-V, и к SPARC.
Подробности: https://doc.rust-lang.org/nightly/rustc/platform-support.html
Причём везде один и тот же диалект языка, а не как у Си того же - каждый компилятор живёт своей жизнью.
>> - объектно-ориентированного программирования
> Си, АдаУ Раста нет объектно-ориентированного программирования, зато есть функциональное и композиционное. Про Ада ничего не знаю. На Си это, скорей всего, можно сэмулировать, но будет куча лишнего кода. Так что мимо кассы.
Gobo linux даже не смогли pendrive install запилить,
> Сначала переделали файловый бардак и сделали Gobo-linux. [...]
> Но это будет уже при наших внуках.Какие ваши внуки, трансгендерно-восхищённые "постчеловеки"?!
// нет, это прям какие-то кульбиты высшего пилотажа в самовляпывании в антиориентиры
PS: технарям, а также сомневающимся, напомню статью Витуса Вагнера примерно двадцатилетней давности, которая за прошедшее время стала только актуальней, как по мне (и теперь выглядит сказочно "неполиткорректной" на фоне того, во что ударными темпами скотился и продолжает скатываться коллективный запад): http://wagner.pp.ru/~vitus/articles/user-friendly.html
Статья примерно из той же оперы что и разговоры малочисленных и нищих совковых автовладельцев о превосходстве "механики" над "автоматом".
Ремонтопригодность? Не, для поколения айфонов и тиктоков это слишком сложная концепция. Лучше заменим всё целиком, а то пепельница переполнилась.
Так ведь и автоматы вполне себе ремонтируют, не?
Как приведенная статья противоречит (опровергает) то, что сделано создателями GoboLinux?Автор статьи, кстати, абсолютно прав: программа должна быть рабом у человека. Сказали - сделала.
GoboLinux организацию файловых систем приближает как раз к такому идеалу - человеку нет нужды задумываться (как в других дистрах) о том, где он может найти те или иные бинарники (и/или другие файлы): они всегда будут находиться в одной и той же стандартной структуре папок. Что же в этом плохого, кроме того, что многие админы (и другие пользователи) уже успели привыкнуть (то есть, по сути прогнуться под создателей дистров) к прежней непрозрачной структуре?
Следующим шагом будет обфускация заголовочных файлов для экономии места и очередного ускорения
Так це наоборот, деобфускация. Вместо заголовков-всё-в-одном, a.k.a. просто-добавь-заголовок, будут самодостаточные заголовочные файлы без дичайших вложений.
Вот щас придёт линус в lkml и покажет всем свой финский палец!
шведский.
Всё-таки финский. Его отец был финном.
а мама таки да?
Шведом. Хоть и гражданином независимой Финляндии.
а есть такие же патчи, только что бы сам комп на столько же быстрее работал?
"Сам комп" не умеет, а так вот небольшой комментарий к нашумевшему недавно тестированию сбером эльбрусов (как водится, неназванный учёный изнасиловал журналиста cnews, а дальше понеслось).Если кто обратил внимание на _три_ столбика на графике SPEC CPU -- поставщиками x86-железа заявляются циферки примерно вдвое больше, чем получается намерить при использовании тех компиляторов и их версий, что в проде у того же Сбера. В некотором смысле было занятно услышать объяснение человека из Intel -- мол, так надо же взять вот эту версию и там к ней ключики указаны... (и такие люди будут ставить на вид МЦСТ их шалости вроде "будем сравнивать производительность, приведённую к частоте")
Короче, если вдруг кому кажется, что у вас в ЦОДы закупается слишком много железа за СЛИШКОМ много бабла -- попробуйте прогнать на нём тесты и сравнить с эталонными результатами. Возможно, из уже имеющегося можно выжать ещё в пару разиков больше, если дать денег не чужим продаванам, а своим специалистам. Да, SPEC просто так не возьмёшь и не прогонишь, но тот же линпак можно и попробовать: с production toolchain/options и с "олимпиадными".
PS: а так-то самому интересно, куда и чьей рукою из технических выводов пропал пункт 3 -- про ограниченную, но уже применимость серийных эльбрусов к поставленным в том тестировании задачам.
Почему-то любое упоминание Эльбрусов наводит меня на воспоминания об одной статье в журнале "За рулём", советских ещё лет, то ли про ГАЗ-14, то ли про ЗИЛ-117, уже не помню... В той статье авторы всячески расписывали этот автомобиль, отмечая продуманную конструкцию, удобство салона и прочие бесспорно имевшие место достоинства данного аппарата. Вот только финал статьи был беспощадно обескураживающим: этот автомобиль создавался в качестве конкурента таким автомобилям как Роллс-Ройс и Кадиллак, предназназначается он для партийного руководства, а главной целью его создания является выполнение представительских функций для поднятия престижа страны; обычные граждане этот автомобиль купить не смогут.
Эльбрус никому не нужен. Это — тупиковая ветвь развития микропроцессоров, поддержанная только деньгами. Желания использовать это убожество никогда ни у кого не возникало.
Отучаемся говорить за всех (с). Я бы купил себе (незадорого), так не продают же.
Не переживай, после того как чуть ли не половина тамошних пламенных борцов за "русский процессор" перешли в Yadro, стоило только помахать у них перед носом хрустящей бумажкой, скоро и продавать будет нечего.
> Я бы купил себе (незадорого), так не продают же.удваиваю. если патриотизм генерирует убытки для своего кошелька,
то пошел в опу такой патриотизм.
>PS: а так-то самому интересно, куда и чьей рукою из технических выводов пропал пункт 3 -- про ограниченную, но уже применимость серийных эльбрусов к поставленным в том тестировании задачам.В перепечатках новости было, я видел. Но там везде в комменты бодро набигала публика с обычным нытьём про распилы, и "лучше бы", так что в целом этот нюанс остался незамеченным.
Если бы не закрытость эльбрусов...
Увы, это характерная черта русского человека - много философствовать о человеческой природе, о добре и зле и прочих высоких материях, но в реальной жизни палец о палец не ударить, чтобы сделать для людей что-то хорошее. МЦСТ даже утопая не протянет руки сообществу. Обратите внимание насколько это контрастирует с США, которые при всех своих недостатках подарили миру множество интересных проектов, многие из которых также были закрытыми, а то и вовсе засекреченными...
Если бы не убогость архитектуры... DSP-переросток.
Они считают это - достижением. Опыт itanium ничему не научил. При том что в нем гораздо меньше было свалено на компилятор (но даже и этого интел нешмог на все интеловские и хулетовы деньги)
> Они считают это - достижением. Опыт itanium ничему не научил. При том
> что в нем гораздо меньше было свалено на компилятор (но даже
> и этого интел нешмог на все интеловские и хулетовы деньги)И ладно бы только итаниум... Эта архитектура была модной лет 25 назад, но в результате - ее все закопали, не только интел.
Я если смутно понимаю как этот монстрик будет оптимизироваться под выполнение в СВМ... Куда пойдет вся его оптимизация в момент переключения контента исполнения?
> мол, так надо же взять вот эту версию и там к ней ключики указаны.и, почему же это не сделано? Если тебя интересует, конечно же, пиковая производительность, а не что-то еще, например - удобство разработки и сопровождения, "а производительности нам просто хватает" (но тут пиломатериалы опять в пролете).
А у МЦСТ НЕТ никакой другой более быстрой версии и волшебных ключиков, краденый код gcc как-то к тому не располагает. Только "приведенный к частоте" FUD и остается.
Я не понял смысл наброса, разве GCC украли EDG фронтенд?
Будем теперь ядро на 486 собирать за ночь
Это ж какая сейчас скорость сборки тормозная если её можно "оптимизировать" на 50-80% 🤣 Мир Линукса как он есть. Без розавых очков.
На стриме у одного человека видел, насколько тормозной на самом деле nasm (это ассемблер, если чё, т.е. даже не в Си дело) и какие жирные бинарники он выдаёт по сравнению с fasm (у которого нету документации, но всё таки). Скорость достаточно небольшого проекта с 7 секунд (включая компилятор его собственного языка) и мегабайта статического бинарника упала до 2 секунд и килобайта статического бинарника. Может стоит ещё и инструментарий чекнуть, не только код линукса.
> и какие жирные бинарники он выдаёт по сравнению с fasm (у которого нету документации, но всё таки).*рукалицо*
Жир бинарника в асме - иключительно вопрос прямизны рук (или желания заморочиться) асмщика.
Что касается документации FASM - все с ней нормально
https://flatassembler.net/docs.php
(причем еще 12 лет назад было - я как раз переписал проектик на пару тыщ строк с MASM на FASM)
Но да, оно в виде текста, а не видосика на ютубе.
> nasmядром используется обычный асемблер из бинутилсов
> Что приятно, в Линуксе таки находятся адекватные люди!та не! этот чел просто захотел славы.
Вот это новогодний подарок! Кто-то начал разгребать эти авгиевы конюшни! Респектище!
По хорошему нужно раз в несколько лет переписывать всё с нуля с оглядкой на актуальное железо, а не тянуть гору костылей, прослоек и надстроек.
Ниче что у Линукса чаще чем всегда проблемы с новыми железками?)
При чём тут линукс? Это обязанность производителя поддерживать железо. Всегда поддержку пилят разрабы на зарплате. Просто с линуксом у анонима есть опция поправить что-то самому, а с вендой через пару лет после покупки всё железо отправляется на помойку. Если оно вообще будет работать, например, усб звуковухи с амдшными камнями не работали, когда я в прошлый раз проверял.
Много ты знаешь пользователей, которые сами драйвера поправляют?
> Много ты знаешь пользователей, которые сами драйвера поправляют?Та даже системный программист не сможет это сделать не имея на руках спецификации от производителя железа.
>> Много ты знаешь пользователей, которые сами драйвера поправляют?
> Та даже системный программист не сможет это сделать не имея на руках
> спецификации от производителя железа.Спеки? Т.е. ситуации, когда уже есть драйвер для аналогичного железа не рассматриваем? Или даже для этого же, но вот сломался. Прямо сейчас в ядре есть хаки для различных модификаций, поддерживаемых драйверами. И для обхода багов железа.
> Много ты знаешь пользователей, которые сами драйвера поправляют?Эээ... ну, я однажды vid&pid в .h-файл добавил. Это считается?
Сколько в итоге денег сэкономили? А сколько времени ушло на то, чтобы разобраться с языком программирования вообще и конкретным драйвером в частности? СтОило оно тех усилий с экономической точки зрения?
> Сколько в итоге денег сэкономили?По сравнению с каким вариантом?
> А сколько времени ушло на то, чтобы разобраться с языком программирования вообще и конкретным драйвером в частности?С основами языка - около месяца на 2м курсе, лет за двадцать с гаком до описываемых событий. С конкретным драйвером - несколько вечеров.
> СтОило оно тех усилий с экономической точки зрения?Опять-таки, смотря как считать. Вариант с перебором аналогов (каждый из которых стОит денег, плюс ожидание доставки, плюс чип внутри заранее неизвестен и может оказаться неподдерживаемым вообще) - этот вариант с экономической точки зрения намного лучше?
> По сравнению с каким вариантом?По сравнению с покупкой нового девайса, который бы работал без переделки драйвера. Мы же в этом контексте находимся.
> Опять-таки, смотря как считать.
Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц. На доработку драйвера старого ушло X денежных единиц. Если N > X, то вы потратили деньги и время впустую (разве что удовольствие получили от самого процесса, но мы подобные вещи не будем брать в расчёт, потому что это выходит за рамки обсуждаемой темы).
> Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц.Но как обычно - только в теории. Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под себя".
Как и повышенные налоговые и соц. отчисления на "заработал денег больше суммы X" и проч.
>> Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц.
> Но как обычно - только в теории.Для подавляющего большинства пользователей, не занимающихся профессионально разработкой драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика.
> Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под себя".
Старый девайс выбирался аналогичным образом. Поэтому здесь паритет и этим временем можно пренебречь.
> Как и повышенные налоговые и соц. отчисления на "заработал денег больше суммы X" и проч.
Если речь идёт о дополнительном заработке (за вычетом налогов) - что здесь может быть плохого?
>>> Очень просто считать. Новый девайс, который бы удовлетворял нуждам, стОит N денежных единиц.
>> Но как обычно - только в теории.
> Для подавляющего большинства пользователей, не занимающихся профессионально разработкой
> драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика.Практика, которая "проста" только у теоретиков.
>> Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под себя".
> Старый девайс выбирался аналогичным образом. Поэтому здесь паритет и этим временем можно пренебречь.Если рассматривать покупки, как независящие сферическо-вакуумные события - все может быть. Однако, вне вакуумной сферы, если старый девайс прослужит дольше, то новый покупается позднее и в итоге выходит N девайсов для временного отрезка t, против N-X для такого же отрезка, при этом следует учитывать не только стоимость этих X девайсов, но и затраты времени на "вникнуть, что сейчас есть на рынке, что хорошо, а что фуфло" и прочее.
>> Как и повышенные налоговые и соц. отчисления на "заработал денег больше суммы X" и проч.
> Если речь идёт о дополнительном заработке (за вычетом налогов) - что здесь может быть плохого?Во-первых, такой возможности на основной работе может и не быть, а искать и оформлять подработку - тоже нужно время. Во-вторых - налоги и отчисления за это дело могут "неприятно" удивить, т.е. тупо взять свою почасавую плату П и посчитать "если я проработаю на Ч часов больше, то получу Ч*П" -- не выйдет.
Поэтому да, "просто было на бумаге, но забыли про овраги!"
>> Для подавляющего большинства пользователей, не занимающихся профессионально разработкой
>> драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика.
> Практика, которая "проста" только у теоретиков.И в чём здесь могут быть сложности? Обычный пользователь считает, что он реально может, что обойдётся ему дешевле, тот вариант и выбирает. Зачастую это выкидывание старой несовместимой с новой ОС железяки и покупка нового девайса.
>>> Потому что еще есть время, затраченное на поиск и покупку, а затем конфигурацию и "допилку под себя".
>> Старый девайс выбирался аналогичным образом. Поэтому здесь паритет и этим временем можно пренебречь.
> Если рассматривать покупки, как независящие сферическо-вакуумные события - все может быть.Если рассматривать покупки с точки зрения обычной логики, то что на выбор старого девайса человек тратил время, что на выбор нового он также потратит время. Эти временные промежутки при одном и том же классе устройств примерно одинаковы, то есть имеем полный паритет.
> Во-первых, такой возможности на основной работе может и не быть, а искать и оформлять подработку - тоже нужно время.
Если нет возможностей на основной работе, то о каких дополнительных заработках и последующих налогах вы вообще говорили? Может тред перечитаете, прежде чем бессвязно отвечать?
>>> Для подавляющего большинства пользователей, не занимающихся профессионально разработкой
>>> драйверов (или не имеющих такого хобби) это не только теория, а ещё и практика.
>> Практика, которая "проста" только у теоретиков.
> И в чём здесь могут быть сложности?В расхождении подсчета "на пальцах" и _реального_ результата.
Ваш Кэп> Если рассматривать покупки с точки зрения обычной логики, то что на выбор
> старого девайса человек тратил время, что на выбор нового он также
> потратит время. Эти временные промежутки при одном и том же классе
> устройств примерно одинаковы, то есть имеем полный паритет.Т.е. "мы можем дольше использовать старое устройство, следовательно количество покупок, как и затраченного ни них времени в общей сумме - будет меньше" вы просто проигнорировали ...
>> Во-первых, такой возможности на основной работе может и не быть, а искать и оформлять подработку - тоже нужно время.
> Если нет возможностей на основной работе, то о каких дополнительных заработках и
> последующих налогах вы вообще говорили? Может тред перечитаете, прежде чем бессвязно отвечать?Потрудитесь расширить кругозор, прежде чем бросаться заявлениями, ну и читать не только по одному предложиению, что ли.
В зависимости от страны проживания, помимо налогов есть отчисления на соц. пакет (пенсия, медстраховка), плюс разные страховки со стороны работодателя.
И нередко - "ступеньчатое", т.е. если вы заработали больше определенной суммы - будет другой "процент". Плюс есть определенные суммы, не облагаемые налогом и это учитывается уже при рассмотре Вашей налоговой декларации (т.е. уже в следующем году).
Поэтому, без обращения к налоговому консльтанту, вполне может оказаться так, что заработали вы вроде бы на 1000 у.е. больше, но получили в итоге на 500 у.е. меньше. И выяснится это только через полгода-год.
> Т.е. "мы можем дольше использовать старое устройство, следовательно количество покупок,
> как и затраченного ни них времени в общей сумме - будет
> меньше" вы просто проигнорировали ...Да, пропустил, извиняюсь. Но что это меняет в корне?
Текущее положение дел таково, что потребитель (обычный, не профессионал или гик) как менял старый девайс на новый, так и будет продолжать это делать, потому что затраты на исправление драйверов в подавляющем большинстве случаев не окупятся (что по времени, что по деньгам). Новый девайс будет и на гарантии, и лучше старого (быстрей, функциональней).Соглашусь, что в какой-то гипотетической реальности это может быть не так (налоги, время на поиски и так далее). Но в объективной реальности от старого хлама при наличии ресурсов избавляются. А вот тем одним процентом анонимусов, любящих поковыряться от нечего делать в дровах этого хлама можно спокойно пренебречь. Или у вас какая-то другая статистика? Если да, хотелось бы подробностей.
> который бы работалКто может это гарантировать заранее?
> стОит N денежных единицПлюс N' денежных единиц за выкинутый старый девайс, на допиливание драйверов которого мы решили не тратить время, плюс потерянное время на ожидание доставки нового девайса, плюс время на выяснение ситуации с драйверами для нового девайса. И это, замечу, без какой-либо гарантии, что новый девайс будет "работать без переделки драйвера".
> Кто может это гарантировать заранее?Очевидно, что производитель девайса.
> Плюс N' денежных единиц за выкинутый старый девайс
Минус амортизация.
> потерянное время на ожидание доставки нового девайса,
Это время ничего не стоит, если только речь не идёт об упущенной выгоде. Если всё-таки идёт, то новые девайсы в таких случаях покупаются заранее.
> плюс время на выяснение ситуации с драйверами для нового девайса
Оно обычно несоизмеримо меньше времени доработки драйвера для старого устройства.
> И это, замечу, без какой-либо гарантии, что новый девайс будет "работать без переделки драйвера".
Производитель обычно даёт такую гарантию. В 99 процентах случаев она работает, хотя в принципе бывает всякое.
> Очевидно, что производитель девайса.Разве Вам никогда не встречались устройства, производитель которых обеспечивает только драйвера для Windows? Ну так они бывают, медицинский факт. И драйвера для Linux пишут умельцы-энтузиасты - хорошо, если есть спеки на чип и в сарае дядюшки Ляо просто клепают платы референсного дизайна, без отсебятины.
> Минус амортизация.
Амортизация считается, емнип, если стоимость имущества переносится на выпускаемую продукцию/услугу. Если оборудование не работало из-за отсутствия драйверов, то потраченная на его покупку сумма - это просто убыток.
> Это время ничего не стоит
Спасибо. Я польщён.
> Оно обычно несоизмеримо меньше времени доработки драйвера для старого устройства.
Опять-таки, зависит от. Бывает, что воткнул - заработало, а бывает, что и с бубном поплясать приходится.
> Производитель обычно даёт такую гарантию. В 99 процентах случаев она работает, хотя
> в принципе бывает всякое.Дык отож...
> Разве Вам никогда не встречались устройства, производитель которых обеспечивает только драйвера для Windows?Встречались. И? Не понимаю, к чему вы клоните. Напоминаю, я вступил в дискуссию после вот такого заявления Анонимуса: "Просто с линуксом у анонима есть опция поправить что-то самому, а с вендой через пару лет после покупки всё железо отправляется на помойку".
> Амортизация считается, емнип, если стоимость имущества переносится на выпускаемую продукцию/услугу. Если оборудование не работало из-за отсутствия драйверов, то потраченная на его покупку сумма - это просто убыток.
Ранее речь шла о том, чтобы поправить драйвер для старой железяки (которая, надо полагать, уже отработала свой срок, отсчитанный производителем) под новую ОС. Почему вы теперь говорите, что оборудование не работало?
>> Это время ничего не стоит
> Спасибо. Я польщён.Я не собирался вам льстить, и ваш сарказм в данном случае не совсем понятен. Время ожидания бесплатно. Это просто констатация факта.
> Опять-таки, зависит от. Бывает, что воткнул - заработало, а бывает, что и с бубном поплясать приходится.
В подавляющем большинстве случаев всё работает сразу при использовании сертифицированной ОС. Если что-то не работает, то вам в любом случае придётся танцевать с бубном:
1. Или чтобы поставить драйвер.
2. Или чтобы поправить исходный код драйвера.С моей точки зрения вероятность того, что время на исправление исходного кода драйвера хотя бы сравняется со временем на попытку поставить драйвер, стремится к нулю.
> Дык отож...
1% не оправдывает возню с исходным кодом драйвера. Проще железку поменять, чем и занимаются в подавляющем числе обычные пользователи-непрофессионалы. Вы - скорее исключение из правил, чем правило. Следовательно опция по предоставлению анонимусу опции что-то поправить самому не оправдана.
> Если оно вообще будет работать, например, усб звуковухи с амдшными камнями не работали,
> когда я в прошлый раз проверял.Да какие там звуковухи -- вон захотели тут давеча ноут с этой их хвалёной win10 в локалку кабелем подключить, своего Ethernet на нём не оказалось, а два оказавшихся под рукой dlink (сотка и гигабит на распространённых чипах, в линуксе что десять лет назад работали, что сейчас) -- "ой, не вижу, поискать в интернете?".
Занавес.
Я человек простой, вижу шигорина, ставлю диз даже не читая.
IT-специалиста, способного купить ноут без eth-разъёма, надо гнать с фирмы тряпками, а не usb-адаптер ему подбирать.
Вакцины от Windows 11 несуществует, мои соболезнования вашим родным и близким.
> По хорошему нужно раз в несколько лет переписывать всё с нуля
> с оглядкой на актуальное железо, а не тянуть гору костылей, прослоек и надстроек.Рожай каждый год нового ребенка, зачем тебе старые, 2-,3-,4-,5-летние дети?
> Рожай каждый год нового ребенка, зачем тебе старые, 2-,3-,4-,5-летние дети?Это какой понос вместо мозгов должен быть чтобы проводить подобные аналогии. Жаль тебя, дядя.
> чтобы проводить подобные аналогииУж не знаю, какой у _Вас_ понос вместо мозгов -- но Вас макнули носом именно в то, что порождаемый Вами и Вам подобными однодневный хлам через год уже "устарел" и нафиг никому не нужен; а то, во что действительно вложены время, силы, душа -- и через сорок лет мило и дорого.
Не спешите отбрёхиваться. Подрастёте -- поймёте, жизнь так устроена.
> то, во что действительно вложены время, силы, душа -- и через сорок лет мило и дорогоИменно поэтому ты сидишь на core 2 duo в 2к22 году? Мило, лол.
Конечно, хорошо, что нашёлся очередной Геракл. Но не лучше бы было просто не доводить до такого, используя более современные и адекватные языки?
А, да, святой Rust эту проблему решит на раз плюнуть.
Может и не на раз плюнуть, но точно с меньшим количеством ошибок работы с памятью и последующей вознёй с их отловом. Плюс масса других вкусных плюшек из коробки.
Скоро Линукс перейдет на zig и ее сборочную систему
make menuconfig тебя не одобряет.
>make -j96Лишь бы ninja не использовать.
> Лишь бы ninja не использовать.Лучше не использовать вне локалхоста, тормозное г..но
Опять у сквирти обострение. Ну, хорошо что залогинился, родной.
> make -j96 vmlinuxСпасибо проорался. Такое количество ядер ни одному гентушнику недоступно.
Среди моих знакомых гентушников есть минимум один бывший админ нескольких вузовских кластеров, который и сейчас, думаю, без проблем столько получит при надобности (правда, на сервере под альтом, но это уже технические подробности). :)
Не важно. Gentoo в chroot можно собирать хоть под Ubuntu, хоть под MX Linux.
Наконец-то кто-то хорошо показал весь бардак в исходниках ядра :) Я когда первый раз туда заглянул, очень грустно мне стало.
50-80%
Это довольно свирепо...
>ускоряющих сборку ядра Linux на 50-80%и че теперь делать?
Компилять
Смотрю в теме одни дистростроители собрались, что не х..., то свой дистриб. А в реальности: apt upgrade. :D
...из бинарного демьяна? ;-}С наступившим!
А ты сам-то кто?
А то нет? Берёшь howto от какого-нибудь "Линукс для себя" и вперёд.
Ага, убираем поддержку rust и станет ещё быстрее.
да просто отключаешь в конфиге сотни ненужных тебе драйверов
Да какую сотню? Один-два учебных.
>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.Каким раком дебажная функция нужна для ускорения сборки?
ты прочитал> to make it more representative
как ускорение ?
не усложнит ли это понимание единицы компиляции? чистка "неиспользуемых хедеров" - это хорошо. но не всякий перекрёстный нелогичен. если есть в одном хедере второй, перекрёстный тому что в юните уже есть, это не исходит из логики по умолчанию, что в первом должен быть второй. и соответственно его не уберут в будущем.
А почему это не делается/проверяется автоматически?
Это повод увеличить мажорный номер версии.
не взлетит. подумаешь, время компиляции. вон, раст компилируется часами, никто и в ус не дует.главное, дети мои, чтоб вы не путались в своих исходничках. чтоб понимали свое творчество, через годик. Документировали, чтоб иной подаван не строил из себя гения фоне вашего кода.
время компиляции тут вообще не имеет роли
Кароч, три дня трахал, компилится быстро, только не грузится. :)