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

"Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, OpenClaw, Nix и ядре Linux"	+/–
Сообщение от opennews (??), 10-Апр-26, 17:36
Несколько выявленных за последние дни  опасных уязвимостей, большинство из которых можно эксплуатировать удалённо:... Подробнее: https://www.opennet.me/opennews/art.shtml?num=65183
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 10-Апр-26, 17:36	+4 +/–
> 5 уязвимостей, выявленных в ходе экспериментов с инструментарием Claude Code И это они ещё с мифосом не экспериментировали...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #70, #90, #95

2. Сообщение от Аноним (2), 10-Апр-26, 17:39	+10 +/–
> OpenClaw https://days-since-openclaw-cve.com/ Days since last OpenClaw CVE - 0 A new CVE was published in the last 24 hours. Because who needs security when you have vibes? Best CVE-less streak - 12 days
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #149

3. Сообщение от Аноним (3), 10-Апр-26, 17:42	–6 +/–
Ужас! Зачем нейронку для их выявления сделали?!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

4. Сообщение от dannyD (?), 10-Апр-26, 17:55	+1 +/–
а представляете, когда-то это все будет работать без косяков и язв!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71, #84

5. Сообщение от Сладкая булочка (?), 10-Апр-26, 17:56	–1 +/–
Чтобы на раст не переписывать. Кстати, получается, что не выгодно. Если ошибок с памятью не будет, то кто будет менять деньги на токены. Думаю притормозят внедрение раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #11, #15, #68

7. Сообщение от Феникс123 (?), 10-Апр-26, 17:57	+/–
Это все ИИ-шески понаходили?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #119

8. Сообщение от Сладкая булочка (?), 10-Апр-26, 17:58	+/–
Интересно найдут ли ошибки в верифицированной библиотеке hacl*? Было бы инетересно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #45

9. Сообщение от 11009 (?), 10-Апр-26, 18:01	+3 +/–
я так понимаю cups чинить уже некому? или нашли очередного беднягу за спасибо?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #91, #98, #121

10. Сообщение от Аноним (11), 10-Апр-26, 18:05	–1 +/–
> GStreamer - 11 уязвимостей: 3 переполнением буфера и 8 уязвимостей вызваны целочисленным переполнением или разыменованием нулевого указателя Ну, Ж-стример всегда отличался какчственным кодом)) > CUPS - 8 уязвимостей, две могут использоваться для организации удалённого выполнения своего кода с правами root Шикарно! А ведь в нем уже находили подобную дырень. > NixOS - Уязвимость даёт возможность перезаписать любой файл в системе ... с правами root. Проблема вызвана некорректным устранением уязвимости CVE-2024-27297 в 2024 году. А как дышали, как дышали! > В ядре Linux устранено 5 уязвимостей, выявленных в ходе экспериментов с инструментарием Claude Code Даже дырявый опенклод находит уязвимости в ядре.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

11. Сообщение от Аноним (11), 10-Апр-26, 18:08	–3 +/–
Так во все эти проекты (особенно в ядро) каждый релиз добавляют 100500 строк нового кода. И если бракоделы будут работать как диды, то такие проверки придется делать постоянно. >Думаю притормозят внедрение раста. Какой славный копиум) Так уже в хроме больше чем 1.5 ляма строк раст кода, в андроиде больше 5 лямов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #19, #158

12. Сообщение от Аноним (12), 10-Апр-26, 18:09	+1 +/–
А сколько уязвимостей может быть не опубликовано в массы а использовано "кем надо" и даже "кем не надо".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #107

13. Сообщение от Аноним (15), 10-Апр-26, 18:09	+/–
> помечена как неопасная так как она проявляется только на 32-разрядных платформах Ха-ха-ха. Так их!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #117, #126

15. Сообщение от Аноним (15), 10-Апр-26, 18:12	+/–
> Думаю притормозят внедрение раста. И кто же, интересно, эти те кто притормозят?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #17, #18

16. Сообщение от Аноним (16), 10-Апр-26, 18:12	+6 +/–
> В ядре Linux устранено 5 уязвимостей, nfsd - не проверили размер буфера и получили out-of-bounds write io_uring - чтение за пределами буфера ksmbd - конвертили unsigned 32 в signed int (как же хорошо что язык это делает неявно) и получили heap buffer overflow - race condition и futex забыли (или забили?) на проверить могут ли флаги не совпадать В общем все как обычно))
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #89, #99

17. Сообщение от Сладкая булочка (?), 10-Апр-26, 18:15	+1 +/–
>> Думаю притормозят внедрение раста. > И кто же, интересно, эти те кто притормозят? Те же, кто дают команду на внедрение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

18. Сообщение от Аноним (-), 10-Апр-26, 18:17	+/–
ОНИ! Судя по всему мысля такова: - подобные проверки требуют много токенов - умственноотсталые будут делать одни и те же уязвимости, как они делают c 1972 года - поэтому проверки надо будет делать постоянно, желательно после каждого коммита - следовательно компании предоставляющие ЫЫ инфраструктуру смогут заработать много денег Идея в общем-то имеет какую-то логику, но вопрос "а нафига это корпам которые код пишут" остается открытым. Не проще ли выкинуть на мороз тех, кто не осиливает новые технологии?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #20, #83

19. Сообщение от Сладкая булочка (?), 10-Апр-26, 18:17	+2 +/–
> такие проверки придется делать постоянно. В этом и цель: деньги за токены. В итоге все счастливы. >>Думаю притормозят внедрение раста. > Какой славный копиум) > Так уже в хроме больше чем 1.5 ляма строк раст кода, в > андроиде больше 5 лямов. Продолжайте вести наблюдение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #21

20. Сообщение от Сладкая булочка (?), 10-Апр-26, 18:20	+/–
> Идея в общем-то имеет какую-то логику, но вопрос "а нафига это корпам > которые код пишут" остается открытым. > Не проще ли выкинуть на мороз тех, кто не осиливает новые технологии? Уязвимости были, есть и будут. Никто не осиливает. Писать низкоуровневый код сложно. Да даже без этого уязвимости будут, только другие. А корпам выгодно иметь дешевых разработчиков. Думайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #22, #48, #57, #97

21. Сообщение от Аноним (-), 10-Апр-26, 18:21	+1 +/–
> В этом и цель: деньги за токены. Цель кого? > В итоге все счастливы. Если корпе сказать "вам не надо тратить деньги на токены, нужно просто внедрить..." то значительная часть задумается. > Продолжайте вести наблюдение. Продолжаю. Дырявые ЯП будут вытеснены на обочину истории. Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #25, #79

22. Сообщение от Аноним (-), 10-Апр-26, 18:24	+/–
> Уязвимости были, есть и будут. Вопрос в количестве. > Никто не осиливает. Вопрос так же в количестве) На плохом языке ты можешь получить рут просто нажав backspace 28 раз. > Писать низкоуровневый код сложно. Особенно если использовать для написания инструменты прошлого тысячелетия. > Да даже без этого уязвимости будут, только другие. Т.е мы избавимся от части уязвимостей? Ну так это отлично. > А корпам выгодно иметь дешевых разработчиков. А еще они любят срезать косты на других направлениях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #27

23. Сообщение от Аноним (-), 10-Апр-26, 18:25	+/–
Или тот же SPARKNaCL
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

24. Сообщение от Аноним (-), 10-Апр-26, 18:27	+/–
Он используется в куче дистрибутивов линукс и даже в бсд. Конечно Сообщество™ не может скинуться по копейке, чтобы нанять человека. Как говорится: узрите силу Сообщества™
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #138

25. Сообщение от Сладкая булочка (?), 10-Апр-26, 18:28	+1 +/–
>> В итоге все счастливы. > Если корпе сказать "вам не надо тратить деньги на токены, нужно просто > внедрить..." то значительная часть задумается. На чем твоя уверенность, что на переписывание + создание новых уязвимостей тратится меньше денен? >> Продолжайте вести наблюдение. > Продолжаю. > Дырявые ЯП будут вытеснены на обочину истории. > Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину. А причина в самой теории вычислимости. Можно только уменьшить симптомы, но проблемы никуда не уйдет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29, #101

26. Сообщение от Аноним (26), 10-Апр-26, 18:30	+/–
> Ну, Ж-стример всегда отличался какчственным кодом)) Я так понимаю, Гном так и не засунул в сендбокс эту индексирующую утилиту и оно до сих пор выполняет все скачанные файлы просто так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #92, #104

27. Сообщение от Сладкая булочка (?), 10-Апр-26, 18:31	–1 +/–
>> Уязвимости были, есть и будут. > Вопрос в количестве. Про что речь? Про "безопасные языки"? Ну вот жс безопасный же. А сколько уязвимостей в npm находят. Вот и думай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #34

29. Сообщение от Аноним (29), 10-Апр-26, 18:45	+/–
>>> Дырявые ЯП будут вытеснены на обочину истории. >> Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину. > А причина в самой теории вычислимости Причина в теории? Ты сам-то хоть понял, что написал? 😂 Нет, причина дыр при работе с памятью - это именно дырявые языки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #31, #33

31. Сообщение от Сладкая булочка (?), 10-Апр-26, 18:51	+/–
>>>> Дырявые ЯП будут вытеснены на обочину истории. >>> Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину. >> А причина в самой теории вычислимости > Причина в теории? Ты сам-то хоть понял, что написал? 😂 Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует, так как это эквивалентно решению проблемы остановки, что принципиально невозможно. Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #35, #37, #40, #44

32. Сообщение от Аноним (29), 10-Апр-26, 18:52	+/–
> В ядре Linux > Уязвимость в драйвере NFS > начиная с ядра 2.6.0 (2003 год). > Claude Code Ахаха! 23 года дырени, и нашлась она только благодаря ИИ. Ну что, воины против ИИ, ваш выход! "Лже-ИИ бесполезен", говорили они. "Лже-ИИ ничего не пониает", говорили они. "Лже-ИИ разбирается только на том, на чем был натренирован", говорили они...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #103, #116, #136

33. Сообщение от Аноним (40), 10-Апр-26, 18:53	+/–
> Нет, причина дыр при работе с памятью - это именно дырявые языки. дырява твоя модель памяти и архитектура Фон-как его там-Неймана!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

34. Сообщение от Аноним (29), 10-Апр-26, 18:55	–1 +/–
> Ну вот жс безопасный же. А сколько уязвимостей в npm находят. А сколько в npm находят уязвимостей типа buffer overflow и double free?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #38, #87

35. Сообщение от Аноним (35), 10-Апр-26, 18:55	+1 +/–
> Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует, А зачем сразу "всех"? Давайте начнем с некого класса ошибок, которые не просто самые распространенные причины CVE, но и приводят к очень плохим последствиям. И распространенность этого класса ошибок можно видеть прям в этой новости. > Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. Ну, т.е раз современной пилой можно попасть по пальцу, то давайте махать каменным топором как диды? Я правильно понял идею?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #42

37. Сообщение от Аноним (29), 10-Апр-26, 18:57	+/–
> Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует А никто и не говорит про все. Речь про проблемы работы с памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #39

38. Сообщение от Аноним (35), 10-Апр-26, 18:59	–1 +/–
Ну шо ты начинаешь?! (с) Тут тебя пытаются убедить что дырявый ЯП еще огого! Надо не только обмазать овнокод санитайзарами, фаззерами, но и запускать регулярную ИИшку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #88

39. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:02	+1 +/–
>> Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует > А никто и не говорит про все. Речь про проблемы работы с > памятью. Про нее и речь. Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe в разных языках и прочие проблемы с асинхронным кодом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #43, #51

40. Сообщение от Аноним (40), 10-Апр-26, 19:02	+/–
> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. зависит от области определения той или иной функции, "типы" как раз и есть те "ограничители" допустимых значений аргументов функций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #47

41. Сообщение от Аноним (41), 10-Апр-26, 19:03	–2 +/–
> В общем все как обычно)) Винда — зло?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #62

42. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:04	+/–
>> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. > Ну, т.е раз современной пилой можно попасть по пальцу, то давайте махать > каменным топором как диды? > Я правильно понял идею? Нет, ты сводишь все к волшебному инструменту, которого нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #80

43. Сообщение от Аноним (43), 10-Апр-26, 19:05	+/–
Есть большая разница "у тебя unsafe только в низкоуровневом коде" и "у тебя весь код unsafe и CVEшка может случиться даже при парсинге строки в UI". Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #49

44. Сообщение от Аноним (29), 10-Апр-26, 19:06	–1 +/–
> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. Ты не понимаешь, что несешь. При формальной верификации кода для каждой функции, ее аргументов и их типов жестко задаются пред/пост-условия и инварианты, и если они отсутствуют или не полны, то верификатор просто откажется дать тебе ответ. Ты бы хоть посмотрел, как это работает в том же Ada/Spark, прежде чем умными словами бросаться. Допущениями решается, блждад...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #52

45. Сообщение от Аноним (40), 10-Апр-26, 19:07	+/–
тут уже спеку на анализ давать надо, а не код (имплементацию)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #78

46. Сообщение от Oe (?), 10-Апр-26, 19:08	+/–
> обработке данных в форматах WAV Прикалываются что ли? Метаданные WAV даже ардуина восьми битная читает
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

47. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:10	+/–
>> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. > зависит от области определения той или иной функции, "типы" как раз и > есть те "ограничители" допустимых значений аргументов функций. Посмотри формальную верификацию чего-либо околосистемного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #53

48. Сообщение от Аноним (40), 10-Апр-26, 19:13	+/–
> Писать низкоуровневый код сложно нет, его писали на листе бумаги, это ваши современные зоопарки ISA привели к тому, что обычному студенту в лом читать 4000 страниц референс мануала по архитектуре ЦПУ, который через полгода будет выкинут на свалку, потому-что и ЦПУ проектирует такие же "дятлы" в угоду прибыли. Архитектура Фон-Неймана - кал!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #154

49. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:14	+/–
> Есть большая разница "у тебя unsafe только в низкоуровневом коде" и "у > тебя весь код unsafe и CVEшка может случиться даже при парсинге > строки в UI". > Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке > будет гораздо легче. Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется. Эти проверки уже идут в райнтайме (смотри miri и сколько багов он нашел в safe коде). Это как раз аналогично тому, что в формализме мы говорим "забей, тут все будет выполняться", а по факту оно не выполняется, например, из-за аппаратной ошибки, чем и пользуются экплуатации уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #56

50. Сообщение от Аноним (50), 10-Апр-26, 19:16	+1 +/–
Там, эээ, как следствие, формат проприетарный и в нём часто через обруч прыгать надо. Как видим, это умеют не только лишь все. Лично мне приходилось патчить туеву хучу софта, чтобы WAVE_FORMAT с fffe поддерживался, иначе файлы тупо не определялись. Показательно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

51. Сообщение от Аноним (29), 10-Апр-26, 19:18	+/–
>>> поиск всех уязвимостей >> Речь про проблемы работы с памятью. > Про нее и речь. Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю. > Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe Главное, что за пределами unsafe в 95% остального кода этих проблем не будет. > прочие проблемы с асинхронным кодом. Давай поподробнее, что это за "проблемы с асинхронностью". Вот с учетом того, что одна из основных целей создания borrow checker была как раз решение всех проблем с асинхронным/многопоточным кодом, а не просто "память не ронять".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #54

52. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:19	+2 +/–
>> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. > Ты не понимаешь, что несешь. При формальной верификации кода для каждой функции, > ее аргументов и их типов жестко задаются пред/пост-условия и инварианты, и > если они отсутствуют или не полны, то верификатор просто откажется дать > тебе ответ. Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать. > Ты бы хоть посмотрел, как это работает в том же Ada/Spark, прежде > чем умными словами бросаться. Допущениями решается, блждад... Покажи мне на ada/spark формально верифицированный аллокатор, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #64, #65

53. Сообщение от Аноним (40), 10-Апр-26, 19:23	+/–
> Посмотри формальную верификацию чего-либо околосистемного. Допустим шедуллер процессов, ввода-вывода, и т.д. и что? Сложно это верифицировать? Думаю даже на оборот, у таких систем строго должна быть описана спека, и всякая имплементация должна быть верифицирована. Не вижу проблемы. Перед тем как писать код какого-либо шедуллера, необходимо написать теоретическую (научную) статью описывающий алгоритм, доказать его корректность и т.д., написать строгую спецификацию с приложениями по имплементации, и только после всего этого писать имплементацию (кодировать), которую собственно потом необходимо верифицировать. А в реальности что? - "я у мамы погромист" или "бабушка, я не нах*р"! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #55

54. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:24	–2 +/–
>>>> поиск всех уязвимостей >>> Речь про проблемы работы с памятью. >> Про нее и речь. > Нет, ты только что пел буквально про "все уязвимости", а не только > те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, > я смотрю. Очередной дешевый тролинг с обвинениями? Продолжать не буду. >> Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe > Главное, что за пределами unsafe в 95% остального кода этих проблем не > будет. Главное не забывать это повторять перед сном. >> прочие проблемы с асинхронным кодом. > Давай поподробнее, что это за "проблемы с асинхронностью". Вот с учетом того, > что одна из основных целей создания borrow checker была как раз > решение всех проблем с асинхронным/многопоточным кодом, а не просто "память не > ронять". Видно, что дальше рекламных буклетов раста ты не смортел. Штош, это было сразу понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #58

55. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:25	+/–
>> Посмотри формальную верификацию чего-либо околосистемного. > Допустим шедуллер процессов, ввода-вывода, и т.д. и что? Сложно это верифицировать? Думаю даже на оборот Мне не важно, что ты думаешь. Найди и покажи такую верификацию, а мы посмотрим, где там допущения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #60, #67

56. Сообщение от Аноним (29), 10-Апр-26, 19:25	+/–
>> Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче. > Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется Конечно будет, потому что количество небезопасного кода сокращается в десятки раз по сравнению с изначальными 100% сишочной лапши. Не говоря уж о том, что вся хитроумная логика и асинхронщина находятся за пределами unsafe. > например, из-за аппаратной ошибки Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные ошибки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #59

57. Сообщение от Аноним (57), 10-Апр-26, 19:27	+/–
> уязвимости будут, только другие Да и слава богу, может те другие будет проще выловить. А если и нет, то всяко интереснее, чем по одним и тем же граблям 50 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

58. Сообщение от Аноним (29), 10-Апр-26, 19:30	+/–
>> Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю. > Очередной дешевый тролинг с обвинениями? Нет, просто констатация того факта, что ты переобуваешься на лету и (как теперь очевидно) не в состоянии отвечать за свои собственные слова. > Главное не забывать это повторять перед сном. > Видно, что дальше рекламных буклетов раста ты не смортел. Штош, это было сразу понятно. > Очередной дешевый тролинг Какая ирония...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #61

59. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:31	–1 +/–
>>> Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче. >> Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется > Конечно будет, потому что количество небезопасного кода сокращается в десятки раз по > сравнению с изначальными 100% сишочной лапши. Не говоря уж о том, > что вся хитроумная логика и асинхронщина находятся за пределами unsafe. У тебя любой примитив синхронизации будет с unsafe внутри.   >> например, из-за аппаратной ошибки > Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные > ошибки. Алгоритмы работают в реальном мире на секунду. Если хочешь рассуждать о них в отрыве, то тебе в теоретики, но тогда проблемы с памятью тебя вообще волновать не должны в твоей модели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #66

60. Сообщение от Аноним (29), 10-Апр-26, 19:32    Скрыто ботом-модератором	+/–
> Мне не важно, что ты думаешь. Найди и покажи В общем, ничего содержательного по теме ты выдать больше не способен. Ну ничего: будет тебе уроком больше не бросаться умными терминами, смысла которых ты не понимаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #63

61. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:34	–1 +/–
>>> Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю. >> Очередной дешевый тролинг с обвинениями? > Нет, просто констатация того факта, что ты переобуваешься на лету и (как > теперь очевидно) не в состоянии отвечать за свои собственные слова. У тебя всегда тролинг строится по одной схеме? Мой тебе совет: пора что-то менять, палишься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

62. Сообщение от Аноним (62), 10-Апр-26, 19:34	+2 +/–
Да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

63. Сообщение от Сладкая булочка (?), 10-Апр-26, 19:37	+/–
>> Мне не важно, что ты думаешь. Найди и покажи > В общем, ничего содержательного по теме ты выдать больше не способен. Ну > ничего: будет тебе уроком больше не бросаться умными терминами, смысла которых > ты не понимаешь. Что, не получилось найти верификацию? А должно было быть "просто" как ты говорил https://www.opennet.me/openforum/vsluhforumID3/139772.html#53 Ну ничего, сейчас щеки надуем, неберем побольше воздуха и выдадим грозный комментарий. Получается, ты бумажный тигр?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

64. Сообщение от Аноним (29), 10-Апр-26, 19:38	–1 +/–
> Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать. Это как раз не исукственные условия - это условия, которые ты контролируешь на уровне алгоритма. Все поведение за пределами алгоритма (например, сломанное железо) к самому алгоритму и его реализации в коде отношения не имеет, и, соответсвенно, чисто физически не сожет быть математически верифицируемым. Это как бы очевидно, не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #77

65. Сообщение от Аноним (40), 10-Апр-26, 19:46	–2 +/–
> Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать. Так и есть, но это ведь не самообман, вы говорите за формальную верификацию как за самообман, тоже самое можно сказать про всю математику, где есть допущения, аксиомы и другие "неловкие" моменты, и все сведется к тому, а что есть собственно понятие - "доказать" (формально доказать). Брауэр вообще не признавал доказательства от противного :) Вот seL4 описали эти моменты: //sel4.systems/Verification/proofs.html //sel4.systems/Verification/implications.html //sel4.systems/Verification/assumptions.html А вот тут про ironclad-os: //ironclad-os.org/formalverification.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #75

66. Сообщение от Аноним (29), 10-Апр-26, 19:47	+/–
>>  что вся хитроумная логика и асинхронщина находятся за пределами unsafe. > У тебя любой примитив синхронизации будет с unsafe внутри. А вся логика снаружи - нет. Об этом как бы и речь. >>> например, из-за аппаратной ошибки >> Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные ошибки. > Алгоритмы работают в реальном мире на секунду. Если хочешь рассуждать о них в отрыве Программные алгоритмы работают, внезапно, сугубо в пределах программы, и чисто физически не могут иметь отношения к потенциальным аппаратным ошибкам. Заканчивай чушь нести.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

67. Сообщение от Аноним (40), 10-Апр-26, 19:48	–1 +/–
> Найди и покажи такую верификацию Вот //sel4.systems/Verification/proofs.html //sel4.systems/Verification/implications.html //sel4.systems/Verification/assumptions.html > Мне не важно, что ты думаешь. Ясно, понятно, только я не тот аноним с которым ты выше троллишся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #74

68. Сообщение от Аноним (29), 10-Апр-26, 19:51	+/–
> Если ошибок с памятью не будет, то кто будет менять деньги на токены. > Думаю притормозят внедрение раста. Не притормозят, а наоборот: закупятся токенами и с помощью ИИ перепишут на Раст еще быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #108

69. Сообщение от Аноним (69), 10-Апр-26, 19:52	+/–
Ахаха... Что-то пилят, всё допилить не могут!
Ответить | Правка | Наверх | Cообщить модератору

70. Сообщение от Аноним (70), 10-Апр-26, 20:16	+12 +/–
Это ещё даже Алису не попробовали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

71. Сообщение от Аноним (71), 10-Апр-26, 20:37	+1 +/–
Никогда не будет. Появятся новые типы уязвимостей, и новые способы защиты от них. Война щита и меча. С ростом мощи искусственного интеллекта люди перестанут в своей массе понимать его выводы, но будут всё больше и больше слепо на него полагаться. Это уже происходит, но это лишь начало. Постепенно даже те, кто будут пытаться его понять, смогут иметь лишь набор возможных интерпретаций относительного того, что он мог бы иметь в виду. В новой форме воскреснут такие средневековые дисциплины, как герменевтика, экзегетика и схоластика, но уже применительно к его отровениям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #76, #86

74. Сообщение от Сладкая булочка (?), 10-Апр-26, 20:52	+/–
>> Найди и покажи такую верификацию > Вот > //sel4.systems/Verification/proofs.html > //sel4.systems/Verification/implications.html > //sel4.systems/Verification/assumptions.html А внутрь ты смотрел? Доказывают они, на самом деле, свойства урезанной статичной версии ядра https://github.com/seL4/l4v/blob/59b2d2f630119be823f3f444651... > This specification is a cut-down version of the seL4 abstract specification > that removes all system calls apart from notifications. The resulting kernel > is a classic static separation kernel without any dynamism. > > A proof that seL4 is equivalent to this cut-down version if configured > appropriately can be found in the `proof` directory under > [`bisim`](../../proof/bisim/). Переходим https://github.com/seL4/l4v/tree/59b2d2f630119be823f3f444651... и читаем > This proof establishes that seL4, if configured fully statically with 1-level CSpaces and notification caps only, is bi-similar to a static separation kernel that has no other system calls than signalling notifications. То есть, доказательтво проводится на статичной конфигурации с тривиальным менеджером памяти, который на практике бесполезен. При этом надежность микроядерной архитектуры надежная, никто не спорит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #115

75. Сообщение от Сладкая булочка (?), 10-Апр-26, 20:53	+/–
>[оверквотинг удален] > верификацию как за самообман, тоже самое можно сказать про всю математику, > где есть допущения, аксиомы и другие "неловкие" моменты, и все сведется > к тому, а что есть собственно понятие - "доказать" (формально доказать). > Брауэр вообще не признавал доказательства от противного :) > Вот seL4 описали эти моменты: > //sel4.systems/Verification/proofs.html > //sel4.systems/Verification/implications.html > //sel4.systems/Verification/assumptions.html > А вот тут про ironclad-os: > //ironclad-os.org/formalverification.html Ответил здесь https://www.opennet.me/openforum/vsluhforumID3/139772.html#74
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

76. Сообщение от dannyD (?), 10-Апр-26, 20:56	+1 +/–
1. все это описанно в книжке Пети Ж.-П. "О чем размышляют роботы?" советское издание 1987 год, оригинал 1982 год. В книге известного французского ученого дается оригинальное изложение основных тенденций развития роботов с программным управлением, адаптацией и элементами искусственного интеллекта, построенное на многочисленных забавных иллюстрациях. Однако такая занимательность подачи материала не означает элементарности содержания. 2. Проблематика "современной" математики, широкой публике непонятна уже более тысячи лет. и что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

77. Сообщение от Сладкая булочка (?), 10-Апр-26, 20:56	+1 +/–
>> Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать. > Это как раз не исукственные условия - это условия, которые ты контролируешь > на уровне алгоритма. Все поведение за пределами алгоритма (например, сломанное железо) > к самому алгоритму и его реализации в коде отношения не имеет, > и, соответсвенно, чисто физически не сожет быть математически верифицируемым. > Это как бы очевидно, не? Нет. Это выставление условий модели удобных для доказательства. В sel4 доказывают не про исходник, а про модель на haskell, доказывают не полные свойства, а некоторые урезанные варианты, в урезанных конфигурациях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #118

78. Сообщение от Сладкая булочка (?), 10-Апр-26, 21:04	+/–
> тут уже спеку на анализ давать надо, а не код (имплементацию) ЕМНИП они заверяли, что там верифицирована работа с памятью. Почему бы не попробовать найти вулны в генерированном си коде?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #120

79. Сообщение от Аноним83 (?), 10-Апр-26, 21:15	+/–
Да да, "The RUST crowd" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

80. Сообщение от Аноним (80), 10-Апр-26, 21:15	+/–
> Нет, ты сводишь все Что "все"? > к волшебному инструменту, которого нет. Ты кажется невнимательно читала. Волшебного инструмента не существует. Есть развитие инструмента - то что мы наблюдаем всю историю человечества. От палки-копалки к деревянной лопате, потом к железной, а потом и к миниэкскаватору. Но некоторые так и остаются с палкой-копалкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

83. Сообщение от Аноним83 (?), 10-Апр-26, 21:18	+1 +/–
Не надо свои заскоки на других переносить. Проверять этой штукой достаточно перед релизами и релизным тестированием. Те кто то раз в пол года будет это делать. После каждого коммита - глупость несусветная и трата времени и денег.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

84. Сообщение от Аноним83 (?), 10-Апр-26, 21:21	+/–
Оно уже работает лет 5-10 без косяков. Падения на цельных данных пролечили, сейчас на всяких специально повреждённых только иногда падает - что вообще никак не мешается в каждодневной работе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #146

86. Сообщение от Аноним83 (?), 10-Апр-26, 21:34	+2 +/–
Один из вырожденных сценариев развития с гиперболизацией роли ИИ. Почему бы не посмотреть на проблему с другой стороны: пузырь ИИ лопнет в ближайший 1-2 года ибо туда инвестированы миллиарды, которые пошли на ДЦ и электричество, а отдачи этих инвестиций НЕТ и не планируется. Проверки кода, генерация ИИ бреда - это всё не даст и 1% возврата потраченного. Обучение новых моделей стоит всё дороже, плюс данных для обучения всё меньше. Можете вспомнить мегахайп про блокчейн 5 лет назад - и где оно теперь? (этим как пользовались полтора фрика так и дальше пользуются) Если взглянуть глобально то человечество подошло к порогу своего развития, когда требуется глубокий рефакторинг. И кремниевые технологии достигли своего физического предела. И знания нуждаются в переработке и очистке: написано 100500 книг, многие из которых не содержат ничего нового, иногда там откровенное враньё. Те данные для обучения нуждаются в чистке. Без этого не получится шагнуть дальше: энергии и производительности не хватит, а загружая мусор в обучащую выборку - будет такой же мусор на выходе. Дурачки за которых ИИ думает - есть уже сейчас. Раньше такие были в религии в основном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #96

87. Сообщение от Сладкая булочка (?), 10-Апр-26, 21:40	+/–
>> Ну вот жс безопасный же. А сколько уязвимостей в npm находят. > А сколько в npm находят уязвимостей типа buffer overflow и double free? Ясно выше написано, что уязвимости этим не ограничиваются, но похоже ты не читаешь. А подобные ошибки в v8 или spider monkey находят регулярно https://app.opencve.io/cve/?product=v8&vendor=google
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

88. Сообщение от Сладкая булочка (?), 10-Апр-26, 21:40	+/–
> Ну шо ты начинаешь?! (с) > Надо не только обмазать овнокод санитайзарами, фаззерами, но и запускать регулярную ИИшку. Внезапно в расте все это есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

89. Сообщение от Аноним83 (?), 10-Апр-26, 21:45	+/–
Учитывая сколько в io_uring находят всякого - похоже там коду академичности не хватило чтобы сделать нормальное архитектурное решение, которое бы не плодило баги в реализации. > race condition > futex забыли (или забили?) Не всегда требуется жёсткая синхронизация через мьютексы и пр, иногда можно забить. Например, для балансировщика нагрузки не критично если случится race и кто то получит чуть больше/меньше заданий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

90. Сообщение от Аноним (90), 10-Апр-26, 21:47	+4 +/–
> через отправку запросов к NFS-серверу узнать содержимое областей памяти ядра. Проблема вызвана ошибкой, проявляющейся начиная с ядра 2.6.0 (2003 год). Это ведь просто баг, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #114

91. Сообщение от Аноним83 (?), 10-Апр-26, 21:48	+/–
А чего было не посмотреть по ссылке в репу?! - там какая то жисть есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

92. Сообщение от Аноним83 (?), 10-Апр-26, 21:52	+2 +/–
Как вы себе представляете это в песочнице?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

95. Сообщение от Витюшка (?), 10-Апр-26, 22:43	+/–
Разве? Так много ошибок в столь разных проектах - я думаю это оно и есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

96. Сообщение от Аноним (29), 10-Апр-26, 22:59	+2 +/–
> пузырь ИИ лопнет в ближайший 1-2 года > И кремниевые технологии достигли своего физического предела. Два года назад местные диванные экономисты писали буквально то же самое. И про "уперлись в технический предел". Но в этот раз точно сбудется, да? Тебе самому-то не смешно? > Можете вспомнить мегахайп про блокчейн 5 лет назад - и где оно теперь? Там же, где и был - в крипте. Кстати, что там по ней? Уже больше 15 лет диванные экономисты предрекают ее крах "вот-вот, совсем скоро уже!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #100, #130

97. Сообщение от Аноним (101), 10-Апр-26, 23:08	–2 +/–
>Да даже без этого уязвимости будут, только другие. Что за булевая логика - есть/нет? Наличие уязвимостей, это вопрос их количества, и их вида. Когда сишник пишет код, он допускает как ошибки управления памятью, так и другие ошибки, вроде неправильной проверки имени файлов. И как бы сишники не бахвалились, от того, что они вручную управляют памятью, другие ошибки никуда не исчезают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

98. Сообщение от Аноним (98), 10-Апр-26, 23:10	+/–
Там чинить то особо нечего. Все принтеры работают как исполнители кода прилетевшего от хрен знает кого хрен знает зачем с правами обычного процесса на компьютере, а не как маленькая стейт-машина для рендера текста на бумаге.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

99. Сообщение от Аноним (98), 10-Апр-26, 23:19	+1 +/–
Как забавно когда баги, которые легко исправляются - это для свидетелей "низкоуровневая работа с памятью должна быть уничтожена" (когда компьютеры буквально только для этого и нужны - читать данные, менять их и писать обратно) большая причина хейтить Линукс, чем переписывание рандомных участков кода который никому не мешал всякими рандомами с "солидными" доменами в коммитах приводят к паникам на системах x86_64 пятилетней давности, выкидыванию на помойку "устаревших" GPU просто потому что чип контроллера переписали на "более красивый лад" "протестив" его работу в виртуалке на макоси/винде, а работающий код выпиливают из ядра потому что "нету мейнтейнера" - буквально должности тела с печатью "я проверил, мамой клянусь"м
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #102

100. Сообщение от Аноним (100), 10-Апр-26, 23:20	+1 +/–
> Два года назад местные диванные экономисты писали буквально то же самое. И про "уперлись в технический предел". Но в этот раз точно сбудется, да? Местные эксперты тут на 2015 год обещали сингулярность и всех в дворники. Но это надо понимать другое? > Там же, где и был - в крипте. Кстати, что там по ней? Уже больше 15 лет диванные экономисты предрекают ее крах "вот-вот, совсем скоро уже!". Как там недиванные? "Ещё пару лет и все банки с свифтами закончатся, всё в крипте" - этому тезису уже больше 15 лет. Или тут тоже не помним?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #131

101. Сообщение от Аноним (101), 10-Апр-26, 23:21	+/–
>А причина в самой теории вычислимости. Можно только уменьшить симптомы, но проблемы никуда не уйдет. Вы забыли привести доказательства. Проблему разыменновывания нулевого указателя можно решить очень просто. Проблему выхода за границы массива можно решить чуть сложнее. И так далее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #106

102. Сообщение от Аноним (101), 10-Апр-26, 23:24	+1 +/–
>Как забавно когда баги, которые легко исправляются Некоторые баги в принципе не должны возникать. Почему программа, содержащая синтаксическую ошибку не компилируется, а программа, содержащая разыменновывание нулевого указателя/выходящая за пределы массива - не просто компилируется, а ещё и память портит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #105, #132, #137

103. Сообщение от Аноним (98), 10-Апр-26, 23:27	+2 +/–
Если бы ты посмотрел на то как в целом работает NFS, включая юзерспейсные инструменты и что они делают с файловой системой (спойлер - рут рутом погоняет и исполняет рандомные пожелания чего угодно, прилетевшего на сокет, который ты даже отдебажить не можешь потому что этот сокет открывается и читается самим драйвером в ядре), то ты бы уже сам давно написал бы юзерспейсную имплементацию на fuse. Это такая же бредятина, как и запихивание драйверов для VPN типа OpenVPN и Wireguard в ядро вместо того чтобы добавлять механизмы для более эффективного контроля пакетов из юзерспейса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #134

104. Сообщение от Аноним (98), 10-Апр-26, 23:37	+/–
От того что ты засунешь процесс в сендбокс, чрутнешь его в /tmp/null, отнимешь все привилегии и setuidнешь его в 2^32-1, багованный код менее багованным не станет и любая неправильно прочитанная пнгшка сможет например задудосить твой комп. Просто нужно выкидывать на мороз фреймворки (GObjectы всякие) с абстракциями и писать парсеры файлов и форматов напрямую как чтение байтиков из памяти. Все файловые форматы - это поток данных от начала и до конца с определёнными опкодами, меняющими состояние парсера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

105. Сообщение от Аноним (98), 10-Апр-26, 23:43	+/–
> программа, содержащая разыменновывание нулевого указателя/выходящая за пределы массива - не просто компилируется, а ещё и память портит? Ни один язык не защищает от этого, просто потому что данные, которые тебе отдаёт операционная система - это просто набор байтиков с длинной. Что внутри них ядро не интересует, и как это интерпретирует Rust код, написанный внутри unsafe потому что ты буквально создаёшь новый вид на память из непроверяемых никак кроме самописной логикой данных из буфера, лежит уже на совести того, кому ты делегировал писать unsafe код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #111

106. Сообщение от Сладкая булочка (?), 10-Апр-26, 23:43	+/–
>>А причина в самой теории вычислимости. Можно только уменьшить симптомы, но проблемы никуда не уйдет. > Вы забыли привести доказательства. Доказательство чего? Проблемы останова? Интернет в помощь. > Проблему разыменновывания нулевого указателя можно > решить очень просто. Проблему выхода за границы массива можно решить чуть > сложнее. И так далее. Можно решить обе проблемы ценой производительности или созданием сложной формализованной системы, которую придется обходить в низкоуровневом коде (привет unsafe).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #110

107. Сообщение от Аноним (98), 10-Апр-26, 23:48	+/–
То же самое можно и про проприетарный код сказать, и про Rust. В последнем вообще баги приходится находить в рантайме в коде ядра, как показывает практика. "ЫЫЫЫ, ЗАТО Я,ЯЯЯ ВЫЗВАЛ КРАШ С ЛОГОМ, А НЕ ЯДРО ПАНИКАНУЛО/ БРАУЗЕР ПРИШИБЛО СЕГФОЛТОМ"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

108. Сообщение от Сладкая булочка (?), 10-Апр-26, 23:48	+/–
> перепишут А сопровождать кто будет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

110. Сообщение от Аноним (101), 11-Апр-26, 00:10	–1 +/–
>Проблемы останова? Как связана проблема останова и разыменновывание нулевого указателя? >Можно решить обе проблемы ценой производительности А то что, память не успеете попортить? >которую придется обходить в низкоуровневом коде (привет unsafe) Вы опять забыли приветси доказательство того, что разыменноывание нулевого указателя, ровно как и выход за границу массива, нужно обходить. Но, даже если вы вдруг окажитесь правы, в чём лично я соменваюсь, то из этого всё равно не следует вывод, что unsafe блоки в этом языке будут хуже, чем язык, который целиком состоит из unsafe.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

111. Сообщение от Аноним (101), 11-Апр-26, 00:13	+/–
>просто потому что данные, которые тебе отдаёт операционная система - это просто набор байтиков с длинной И что дальше? Если ядро не попортило память приложению, то приложение само себе память портить не должно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #127

114. Сообщение от Аноним (114), 11-Апр-26, 00:31	+1 +/–
Фича,а вот в БСД это ЦВЕ и не такой старый как эта Линукс-фича.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

115. Сообщение от Аноним (40), 11-Апр-26, 00:48	–2 +/–
> А внутрь ты смотрел? ой все понятно, ЫЫ-шный бот очередной. Вот https://github.com/seL4/l4v/blob/master/README.md Overview The repository is organised as follows. spec: a number of different formal specifications of seL4     abstract: the functional abstract specification of seL4     sep-abstract: an abstract specification for a reduced version of seL4 that is configured as a separation kernel Что ты мне на урезанную спеку указываешь? Ты в директорию abstract смотри. А вот директория доказательств. //github.com/seL4/l4v/blob/master/proof/README.md This directory contains the formal proofs about seL4, which mostly prove properties about the various seL4 specifications. Each such proof lives in its own subdirectory: access-control - Access Control Proof asmrefine - Assembly Refinement Proof bisim - Bisimilarity of seL4 with a static Separation Kernel capDL-api - CapDL API Proofs crefine - C Refinement Proof drefine - CapDL Refinement Proof infoflow - Confidentiality Proof invariant-abstract - Abstract Spec Invariant Proof refine - Design Spec Refinement Proof sep-capDL - CapDL Separation Logic Proof A proof that seL4 is equivalent to this cut-down version if configured appropriately can be found in the proof directory under bisim. перевод нужен? > Переходим в bisim и читаем там еще куча других директорий пройдись по ним тоже. > То есть, доказательтво проводится на статичной конфигурации с тривиальным менеджером памяти, который на практике бесполезен. бред!!! Вот все доказательства access-control - Access Control Proof asmrefine - Assembly Refinement Proof bisim - Bisimilarity of seL4 with a static Separation Kernel capDL-api - CapDL API Proofs crefine - C Refinement Proof drefine - CapDL Refinement Proof infoflow - Confidentiality Proof invariant-abstract - Abstract Spec Invariant Proof refine - Design Spec Refinement Proof sep-capDL - CapDL Separation Logic Proof
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #140

116. Сообщение от Аноним (90), 11-Апр-26, 00:48	+/–
> и нашлась она только благодаря ... ... тому, что стала неактуальной из-за применения ИИ, который создал более актуальные вещи взамен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

117. Сообщение от Аноним (90), 11-Апр-26, 00:49	+/–
Какая удобная уязвимость!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

118. Сообщение от Аноним (40), 11-Апр-26, 00:50	+/–
> В sel4 доказывают не про исходник, а про модель на haskell, доказывают не полные свойства, а некоторые урезанные варианты, в урезанных конфигурациях. п*здешь и провокация, открой директорию proof
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #123

119. Сообщение от Аноним (90), 11-Апр-26, 00:53	+/–
Ну да, ИИ начали учить, дали почитать документы Центра Развлекательных Увлечений, там столько интересного нашлось, что ИИ смог рассказать про баги в ядре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

120. Сообщение от Аноним (40), 11-Апр-26, 01:07	+1 +/–
No dynamic memory allocation C NaCl is intended to be usable in environments that cannot guarantee the availability of large amounts of heap storage but that nevertheless rely on their cryptographic computations to continue working. C NaCl functions do not call malloc, sbrk, etc. They do use small amounts of stack space; these amounts will eventually be measured by separate benchmarks. This feature applies only to C NaCl. Higher-level languages such as Python are not currently usable in restricted environments. Ну а в чем проблема верифицировать это? Нет динамической работы с памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #122

121. Сообщение от Аноним (121), 11-Апр-26, 01:25	+/–
Там же кажется 2, что ли, чела из эпл его пилили, они его и в эпле пилили, а теперь пилят без эпла, но это не точно. А еще вопрос помимо cups, серверы печати для линукса есть еще? А то они кажись вперли ipp-usb и то ли по этой причине то ли нет, но принтера подключенные через юсбу и не поддерживающие "протокол? 7/4/1", отвалились причем система их видит а капс нет. И шо с ентим всем делать хо.зэ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #141

122. Сообщение от Сладкая булочка (?), 11-Апр-26, 01:25	+/–
> No dynamic memory allocation > C NaCl is intended Я говорил про hacl* https://github.com/hacl-star/hacl-star
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #133

123. Сообщение от Сладкая булочка (?), 11-Апр-26, 01:26	+/–
>> В sel4 доказывают не про исходник, а про модель на haskell, доказывают не полные свойства, а некоторые урезанные варианты, в урезанных конфигурациях. > п*здешь и провокация, открой директорию proof https://www.opennet.me/openforum/vsluhforumID3/139772.html#74
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #124

124. Сообщение от Аноним (40), 11-Апр-26, 01:38	–1 +/–
> https://www.opennet.me/openforum/vsluhforumID3/139772.html#74 ты там на урезанную (reduced version of seL4) версию СПЕКИ указываешь, зачем? Там рядом полная спека, а в директории proofs ее доказательства. Что ты этим хочешь сказать? что там нет полного доказательства? abstract: the functional abstract specification of seL4 sep-abstract: an abstract specification for a reduced version of seL4 that is configured as a separation kernel
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

126. Сообщение от Аноним (101), 11-Апр-26, 01:46	+/–
Но ведь код для 32-бит уже написан, он же не требует поддержки! Или нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

127. Сообщение от Аноним (90), 11-Апр-26, 01:51	+1 +/–
> приложение само себе память портить не должно Да ладно! Это первое, что делает приложение со своей памятью. Вот смотри: перепутал программист на расте знаки > и <, записал в переменную не то число, а потом передал это значение в unsafe блок, который указателями оперирует... Кто виноват?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #128

128. Сообщение от Аноним (90), 11-Апр-26, 01:53	+/–
P.S. Не думайте, что это надуманная история. Знаки сравнения путали в FF.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

130. Сообщение от Аноним83 (?), 11-Апр-26, 02:20	–2 +/–
У вас будут аргументы технического и экономического плана чтобы возразить? По краху крипты - не ко мне. Щиткойны не нужны, стейблкойны - нормальный инструмент. Всякие полущиткойны типа эфира - нужны в мизерных количествах для оплаты транзакций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

131. Сообщение от Аноним83 (?), 11-Апр-26, 02:20	+/–
Свифт в этом году заапгрейдят капитально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #152

132. Сообщение от Аноним83 (?), 11-Апр-26, 02:27	+/–
Потому что мир сложнее чем ты можешь понять. Адрес NULL является валидным адресом, и ты сам можешь туда смапить память. Как минимум это зависит от настроек ОС и самой ОС. В С массивов нет, есть арифметика с указателями. Поэтому выхода за пределы массива на С тоже нет. Просто язык даёт некий синтаксический сахар для удобства этой арифметики. Есть выход за границы рассчётной памяти для конкретного "объекта". Притом это может означать что либо ты прочитаешь соседние участки с другими данными или попадёшь на  не смапленую страницу памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

133. Сообщение от Аноним (40), 11-Апр-26, 02:31	+/–
ой попутал, писали тут про hacl*, вроде The code for all of these algorithms is formally verified using the F* verification framework for memory safety, functional correctness, and secret independence (resistance to some types of timing side-channels). Все спеки есть, код экстрактят из F* в С с помощью KaRaMeL. Обсуждали это уже. KaRaMeL (formerly known as KReMLin) is a tool that extracts an F* program to readable C code: K&R meets ML! If the F* program verifies against a low-level memory model that talks about the stack and the heap; if it is first-order; if it obeys certain restrictions (e.g. non-recursive data types) then KaRaMeL will turn it into C. We have written 120,000 lines of Low* code, implementing the TLS 1.3 record layer. As such, KaRaMeL is a key component of Project Everest. HACL*, our High Assurance Crypto Library, provides numerous cryptographic primitives written in F*; these primitives enjoy memory safety, functional correctness, and some degree of side-channel resistance -- they extract to C via KaRaMeL. Тут надо скорее KaRaMeL проверять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

134. Сообщение от Аноним83 (?), 11-Апр-26, 02:35	+/–
TLS втащили в ядро, и с точки зрения программ это удобно. С точки зрения производительности тоже. А раз он там - то чего бы не заюзать его и в опенвпн. Ваергард - относительно примитивный, втащить такое в ядро не сложно, и там ему и место - нефиг пакеты в юзерспейс почём зря гонять. Пакеты из юзерспейса в 2026 году - есть масса способов, только все они намного более громоздкие и сложные. Те есть громоздкие и быстрые и не очень громодкие но медленные. Юзерспейсная имплементация NFS называется SFTP+SSHFS. Мне нравится больше остальных, но у меня требования к этому довольно скромные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #147

136. Сообщение от Аноним83 (?), 11-Апр-26, 02:36	+/–
И кому оно там мешало?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

137. Сообщение от Аноним (137), 11-Апр-26, 02:45	+/–
Потому что для процессора работа с памятью - это чистая математика, а не манипуляция с какими-то объектами и границами. Ложки не существует. Границ тоже нет. Все границы лишь в голове людей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

138. Сообщение от _ (??), 11-Апр-26, 02:49	+/–
Не-а! Ну то есть оно там есть, но вот в энтерпрайзе их манёвр с выпиливанием драёверов не оценили, старые системы доживают на cups-1.* (моя последняя - на двойке, но _до_ 2.3) Новые такое ощущение что вообще все поголовно - на винде с PaperCut-ом :( Новых принт фабрик ка линуксе более не наблюдается, производители НЕ кинулись писать CUPS-принтинг-аппы под него, а PPD - выпилен...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #156

140. Сообщение от Сладкая булочка (?), 11-Апр-26, 02:53	+/–
>> А внутрь ты смотрел? > ой все понятно, ЫЫ-шный бот очередной. И зачем тут эта простыня? На конкретный вопрос ответить не получется?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #145

141. Сообщение от _ (??), 11-Апр-26, 02:57	+/–
Ставь старый CUPS с драйверами, если знаешь как. Но он дырявый так что аккуратно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #150, #151, #157

143. Сообщение от Ананоним (?), 11-Апр-26, 03:43	+5 +/–
Чё вы так все раскудахтались? Для начала бы устранили все предупреждения компиляторов из используемого кода. А то как компиляю сторонние пакеты, волосы дыбом встают.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #144

144. Сообщение от Сладкая булочка (?), 11-Апр-26, 04:38	+1 +/–
> Чё вы так все раскудахтались? Для начала бы устранили все предупреждения компиляторов > из используемого кода. А то как компиляю сторонние пакеты, волосы дыбом > встают. Правильно! -Wall -Wextra -Werror -Wpedantic. Еще пусть санитайзеры включат!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

145. Сообщение от Аноним (40), 11-Апр-26, 04:58	–1 +/–
> Найди и покажи такую верификацию Нашел и показал!!! > И зачем тут эта простыня? За тем, что ты не знаешь к чему придраться, и несешь ересь по поводу верификации seL4, говоря вот это "Доказывают они, на самом деле, свойства урезанной статичной версии ядра".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

146. Сообщение от dannyD (?), 11-Апр-26, 05:28	+/–
на x86 - да, на остальном - пока под вопросом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #165, #167

147. Сообщение от Аноним (98), 11-Апр-26, 06:28	+/–
> TLS втащили в ядро, и с точки зрения программ это удобно. Спору нет что это удобно, но не настолько как если бы можно было поднять собственный провайдер-резолвер сокетов (типов которых для передачи данных надо два с половинкой: SOCK_STREAM и SOCK_DGRAM, плюс вариации на тему датаграм), и тогда можно хоть в тор прозрачно всю систему запихнуть или роутить свои собственные протоколы, хоть в онион всю систему прозрачно запихнуть не выкручиваясь с перехватом вызовов функций стандартной библиотеки через LD_PRELOAD. Это бы в том числе позволило наконец-то внести доменную систему под контроль администратора тачки, а не надеятся на то что программа сама сможет резолвнуть в нужном резолвере хотя-бы через getaddrinfo всё что нужно (если она вообще будет использовать +/- стандартизированные функции, а не как сейчас очень многие просто забивают на резолвинг хостнеймов и либо парсят их как домены, либо как ipv4, напрочь забивая на ipv6). Плюс реализовывать TLS внутри ядра, т.е. полноценную стейт-машину с кучей расширений и богатой историей различного рода уязвимостей - это идиотизм. libssl можно хотя-бы пропатчить на ходу, или запустить разные версии на одной тачке, на то юзерспейс и нужен. Ядерную реализацию придётся свапать гася всю систему, не говоря уже о разнице между багами в юзерспейсе и багами в контексте исполнения ядра. > С точки зрения производительности тоже. Чушь полная. Единственное, что в том же OpenVPN медленного - это отсутствие адекватного интерфейса ядра для распараллеливания работы с очередью пакетов. Есть только всратый TUN/TAP с серийной отдачей пакетов через read/write, причём нет никакой гарантии что пакет не придётся копировать между кэшами CPU который исполняет обработку пакета в OpenVPN и кэшом CPU который этот пакет прочитал/будет отправлять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #164

149. Сообщение от penetrator (?), 11-Апр-26, 08:41	+/–
по всей видимости они и писали его с помощью того же самого агента
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

150. Сообщение от Аноним (121), 11-Апр-26, 10:24	+/–
Уже а результат тот же, но не совсем, теперь cups пишет что нет доступа к устройству, права проверены, правтла внесены. Продолжаем разбираться что за :))) спасибо за совет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

151. Сообщение от Аноним (121), 11-Апр-26, 10:26	+/–
Ой, старый кас не устанавливался, а что теперь все, на новом работать не будеть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

152. Сообщение от Аноним (100), 11-Апр-26, 10:36	+/–
Единственное что слышал сделают сложнее и в несколько раз медленнее будет работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

154. Сообщение от Аноним (154), 11-Апр-26, 10:54	+/–
>это ваши современные зоопарки ISA привели Повальные скачки вокруг недопроцессоров (RISC) в 90-х и банальная лень привели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #163

156. Сообщение от Аноним (100), 11-Апр-26, 11:24	–1 +/–
Ой, а что случилось? Неужели люди не кинулись на гораздо более лучший линукс а остались жевать вин?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

157. Сообщение от Аноним (157), 11-Апр-26, 12:16	+/–
Хм.. т.е ты предлагаешь заменить новый дырявый КУПС на старый, тоже дырявый? Отличный план _! Просто офигенный, если я правильно понял. Надежный как швейцарские часы!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #166

158. Сообщение от aname (ok), 11-Апр-26, 13:04	+/–
Так такие проверки и будут делать постоянно, в этом и суть прооверок кода. Понятно, что растухи не понимают, зачем делать проверки кода, отсюда и всплывают всякие реализации работы с TCP/IP и прочие CVE в ядре линуха, но с теми, кто лечит здоровое разговаривать должны специалисты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

161. Сообщение от Аноним (40), 11-Апр-26, 15:22	+/–
ты по этим ссылкам прошелся или нет? //sel4.systems/Verification/proofs.html //sel4.systems/Verification/implications.html //sel4.systems/Verification/assumptions.html По этой ссылке //sel4.systems/Verification/proofs.html есть картинка, может так яснее тебе будет? The seL4 proofs span the following top-level properties. Functional correctness: the C code of all verified configurations of seL4 behaves precisely as specified in the seL4 specification and nothing more. This is the strongest assurance that the code will not have any unspecified behaviour. Note that not all properties are available on all platforms and all configurations. See the list of verified configurations for the current status of what is available. //docs.sel4.systems/projects/sel4/verified-configurations.html The properties listed above are what the proofs show directly. A side effect of the strength of these statements is that they also imply that seL4 is free from whole classes of common programming errors such as buffer overflows, null pointer dereferences, memory leaks, arithmetic exceptions or undefined behaviour. See the page on proof implications for more. How Strong are the Proofs? We claim that seL4 has world's highest level of assurance for an operating system kernel. On the research level, this is substantiated by the following facts: formal verification in general is stronger than other traditional ways of gaining trust in software such as testing in that it can prove the absence of bugs, not just their presence. within systems that are claimed to be formally verified, seL4's proof stack goes down to the binary code. This massively reduces the assumptions it relies on, compared to verification projects where the system model stays at a more abstract level. within existing formal verification approaches, the seL4 proofs target strong properties, such as functional correctness and explicit security theorems. More traditional techniques such as static analysis often only target the absence of specific classes of programming errors, which are implied by the seL4 proofs. within tools that can be used for formal machine-checked proof, the seL4 proofs use the proof assistant Isabelle/HOL, which is engineered to minimise the code that needs to trusted for the proof to be correct — see more on the assumptions page. This means in all dimensions of measuring the strength of formal verification, detail of model, depth of property, and correctness of the prover, seL4 is on the highest levels. All these arguments are nice, but they are abstract. There is something more concrete: we can measure how strong these proofs are in practice. Before we turn to seL4 itself, there is a research paper about Finding and Understanding Bugs in C Compilers that makes empirical observations about the CompCert C compiler. Like seL4, CompCert also comes with a functional correctness proof, and this is what the authors find: The striking thing about our CompCert results is that the middle-end bugs we found in all other compilers are absent. As of early 2011, the under-development version of CompCert is the only compiler we have tested for which Csmith cannot find wrong-code errors. This is not for lack of trying: we have devoted about six CPU-years to the task. Now turning towards seL4, there are test suites in addition to the formal verification: one for performance tests and one for functional tests. Why have these if there is formal verification? Here are some of the classes that are still interesting to test: Code in the verified kernel that is left as an assumption, e.g. machine interfaces such as caching. These can be tested and have a fairly high density of tests. Code in unverified configurations of the kernel — things that are either not yet verified or are only for debugging or are for platforms/configuration combinations that are unverified. Tests for verified code to confirm expectations: this is testing the specification. It is less about coverage, more about usability and confirming that the API is what the developers were intending, as opposed to what the specification says or what is implemented. It is also helpful when such tests break on code changes before these are verified. In addition to the test suites, there are also integration tests with various user-level libraries and frameworks to make sure that they still work (or are updated appropriately) when we make a change to the kernel API. This means there are a lot of tests that run frequently, hundreds for every code change. seL4 also has been in continued deployment for over a decade. This gives us some data. In all this time, there have been no functional correctness defects in verified code since the functional correctness proof completed in 2009 — more than 15 years of tests, use, and deployment. There have also never been any integrity defects in verified code since the integrity proofs finished, and so on. To contrast how remarkable 0 defects in 15 years are: defect density in unverified configurations of seL4 is overall lower than in normal software, but it is not zero. This means there have been defects discovered even in mature unverified configurations of the kernel (e.g. multicore SMP, or x64 VT-x virtualisation extensions), and even in verified configurations we have detected small defects in every class of unverified code in the kernel in that time — hardware assumptions, compiler assumptions, unverified boot code. As the saying goes: everything that can go wrong will eventually go wrong. All the more remarkable that in the entire 10,000 lines of verified code nothing has gone wrong in all that time. This is not surprising, we have a proof for that after all, but it can be hard to grasp. Перевод нужен или сам справишься?
Ответить | Правка | Наверх | Cообщить модератору

163. Сообщение от Аноним (40), 11-Апр-26, 15:52	+/–
> и банальная лень привели. лень писать новый код? лень обычно включается когда повторяешь какие-то действия, для нового кода лень не помеха, просто не было культуры опенсорса и шеринга исходников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #168

164. Сообщение от Аноним83 (?), 11-Апр-26, 17:59	+/–
Видимо ваши хотелки не настолько востребованы чтобы их реализовали. TLS в ядре не целиком, насколько я знаю. Туда утащили только шифрование, а всё что касается обмена ключами и прочее вынесено в юзерспейс. Те на сокет данные валятся сразу расшифрованные и писать можно как в обычный - для приложения всё прозрачно, но требуется дополнительные штуки в сокет писать/читать для общение с TLS либой которая с ключами и прочим работает. Насчёт tun/tap - как будто если написать другое оно как то ещё будет работать. В бсд есть нетграф, но там точно так же через ядро пойдёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

165. Сообщение от Аноним83 (?), 11-Апр-26, 20:48	+/–
Вам виднее. Основная часть кода должна нормально - так же работать на не х86. Исключение доступ к невыровненной памяти: х86 на таком просто незаметно притормаживает а ARM вываливает аппаратное исключение и процесс падает. В С коде такое не шибко часто используется. Но вот гемени от гугла мне недавно как раз такой забагованный код сгенерировал как пример на мой вопрос :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

166. Сообщение от _ (??), 11-Апр-26, 23:27	+/–
Как сказал один злой PM: "тебе печатать или шашечки?!?!?" Мне в том сетапе - пофиг, в той сети незарегистрированный MAC никакого траффика вообще не получит, там только "одобренные комитетом", а потому более-менее до звезды. Решение - хорошее, печатает сразу на кластер больших принтаков (Ricoh) с HA & HP в printing room, за ночь под десятку тыс. наборов (конвертов) с репортами, балансами и прочей мутней для клиентофф. Туда не всякий даже директор зайти может :) Но да - на старом красношляпе и купсе ... Если же ты делаешь печать тупо для всей офисной сети - то можно реально огрести. "Вас предупреждали!(С)" :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

167. Сообщение от Аноним (154), 11-Апр-26, 23:29    Скрыто ботом-модератором	+/–
Не-х86 не нужны. Они все оказались на свалке истории (ARM там же место, и он полу-RISC), оставив в наследство убогие архитектуры ядер ОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

168. Сообщение от Аноним (154), 11-Апр-26, 23:35	+/–
>просто не было культуры опенсорса и шеринга исходников. Было с 80-х минимум. Лень - это про читать мануалы по процессорам и засетапить хотя бы разные дескрипторы для сегментов ведра и юзерспейса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

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

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