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

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

Сообщения

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

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

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

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

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

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

6. Сообщение от Аноним (6), 03-Янв-22, 11:30	+/–
j96? дайте мне такую машину
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #43, #128, #259, #330

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

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

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

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

12. Сообщение от Anonnnym (?), 03-Янв-22, 11:41	+1 +/–
В C++ есть модули. С разморозкой Вас
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #19, #20, #221

13. Сообщение от Schwonder Reismus (?), 03-Янв-22, 11:41	+/–
Другие варианты есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36. Сообщение от Аноним (40), 03-Янв-22, 12:16	–2 +/–
Так ведь Delfi вроде мертв.Не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #101

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

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

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

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

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

42. Сообщение от iZEN (ok), 03-Янв-22, 12:26	–2 +/–
> Потому что это именно так и устроено - каждый дельфёвый модуль - > это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой > набор функций и использует функции других библиотек. Т.е. ничем концептуально не > отличается от проекта на си, состоящего из нескольких десятков статически слинкованных > библиотек. Когда пишешь на 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ообщить модератору
Родитель: #34 Ответы: #65

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

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

45. Сообщение от kot to (?), 03-Янв-22, 12:31	–2 +/–
Про Rust Уже вспомнили ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #70, #78, #346

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

69. Сообщение от Аноним (65), 03-Янв-22, 13:24	–1 +/–
Смешно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #75

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

107. Сообщение от А где же каменты (?), 03-Янв-22, 15:13	+/–
Merge комиты выглядят уродливо. Какие у merge стратегии преимущества перед rebase?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #120, #169, #196, #314

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

158. Сообщение от Аноним (-), 03-Янв-22, 18:25	+1 +/–
make menuconfig тебя не одобряет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

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

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

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

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

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

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

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

166. Сообщение от dflgjldfgjoldigjoildfjg (?), 03-Янв-22, 19:30	+2 +/–
minix everywhere - intel me :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #344

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

186. Сообщение от Аноним (186), 03-Янв-22, 22:34	–6 +/–
reiser4?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

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

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

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

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

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

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

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

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

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

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

197. Сообщение от JavaScript (??), 03-Янв-22, 23:49	+/–
Питоновцы изобретают Веб-Воркеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #397

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

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

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

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

202. Сообщение от john_erohin (?), 04-Янв-22, 01:48	–2 +/–
шведский.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #210

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

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

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

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

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

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

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

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

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

213. Сообщение от Аноним (-), 04-Янв-22, 09:39	–1 +/–
Это русский?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #267

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

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

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

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

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

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

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

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

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

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

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

225. Сообщение от Аноним (225), 04-Янв-22, 11:41	–1 +/–
а мама таки да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

247. Сообщение от Аноним (247), 04-Янв-22, 14:37	–4 +/–
Там гибрид.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

274. Сообщение от Michael Shigorin с дороги (?), 04-Янв-22, 17:33	+/–
> руст с его нпм Чего?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239 Ответы: #353

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

315. Сообщение от pavlinux (ok), 05-Янв-22, 05:18	–1 +/–
....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

316. Сообщение от pavlinux (ok), 05-Янв-22, 05:20	–1 +/–
>x86/kbuild: Enable CONFIG_KALLSYMS_ALL=y in the defconfigs >Most distro kernels have this option enabled, to improve debug output. >Lockdep also selects it. >Enable this in the defconfig kernel as well, to make it more > representative of what people are using on x86. Каким раком дебажная функция нужна для ускорения сборки?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #378

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

340. Сообщение от uis (ok), 05-Янв-22, 13:52	–1 +/–
Hurd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #361

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

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

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

344. Сообщение от uis (ok), 05-Янв-22, 14:05	+/–
Официально Таненбаум негодует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

361. Сообщение от pofigist (?), 05-Янв-22, 15:37	+1 +/–
И? Каковы итоги?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #340

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

382. Сообщение от Аноним (234), 06-Янв-22, 06:36	+/–
Когда крыть нечем, но что-то выcpать надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333 Ответы: #386

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

425. Сообщение от uis (ok), 11-Янв-22, 17:04	+/–
Ну и сиди на apache
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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