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

"Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Emacs"	+/–
Сообщение от opennews (??), 01-Апр-26, 14:38
Во FreeBSD устранена уязвимость... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65118
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+9 +/–
Сообщение от Аноним (1), 01-Апр-26, 14:38
>Vim и Emacs Когда ещё можно услышать вместе эти два названия?
Ответить | Правка | Наверх | Cообщить модератору

	12. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+7 +/–
	Сообщение от Useruser (?), 01-Апр-26, 14:53
	Vim vs emacs
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+5 +/–
	Сообщение от вдцлсоцжтчфлыь (?), 01-Апр-26, 21:20
	в evil-mode
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–4 +/–
Сообщение от Аноним (2), 01-Апр-26, 14:38
FreeBSD нужно переписать на FreeGNU, а GNU/Linux на BSD/Linux!!
Ответить | Правка | Наверх | Cообщить модератору

	6. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (6), 01-Апр-26, 14:46
	Debian GNU/kFreeBSD
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от анонимус (??), 01-Апр-26, 14:49
	уже мертво
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (-), 01-Апр-26, 16:41
	>  Debian GNU/kFreeBSD Так там тоже уязвимый кернель тогда будет...
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	26. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от Аноним (26), 01-Апр-26, 15:32
	И оба переписать на Emacs Lisp.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	81. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (81), 01-Апр-26, 23:33
	Emacs давно нужно собственное ядро, примерно всё остальное там уже есть.
	Ответить | Правка | Наверх | Cообщить модератору

3. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+3 +/–
Сообщение от Аноним (3), 01-Апр-26, 14:41
15-ю после релиза покрутил у себя немного, хорошо работала без сбоев. https://www.freebsd.org/ru/ Кто-нибудь ставил себе, какие впечатления ?
Ответить | Правка | Наверх | Cообщить модератору

	4. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–3 +/–
	Сообщение от пох. (?), 01-Апр-26, 14:44
	можно, но зачем?!
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (8), 01-Апр-26, 14:49
	Чтобы почувствовать запах ылитарности и академичности. И немного запах нафталина. Но ладно, не хурд и слава богу, не буду осуждать чужие странности)
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (21), 01-Апр-26, 15:15
	Академичность - это в нетбсдшке.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (29), 01-Апр-26, 15:36
	> Академичность - это в нетбсдшке. Простите. В сортах бсд разбирают плохо. Так что вам виднее :)
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+3 +/–
	Сообщение от Аноним (8), 01-Апр-26, 19:09
	Знал универсиетских преподавателей они душой тяготели почему-то к FreeBSD. Если академичность то скорее это именно FreeBSD.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	75. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (75), 01-Апр-26, 23:05
	> Чтобы воспламенить у опеннетовского анонима жжение от чужого запаха ылитарности и академичности. Можешь не благодарить.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	62. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (62), 01-Апр-26, 19:38
	Ровно за тем, зачем ставят линукс. Удобнее решать свои задачи.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	65. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 01-Апр-26, 19:41
	но какие?!
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Savaoff (?), 01-Апр-26, 23:07
	Jail иногда очень удобен (Делал на jail коммерческий хостинг еще в 2000м году)
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (108), 02-Апр-26, 16:36
	> Jail иногда очень удобен Когда именно? При каких обстоятельствах? > (Делал на jail коммерческий хостинг еще в 2000м году) Прошло 26 лет с тех пор.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (112), 02-Апр-26, 16:55
	>Когда именно? При каких обстоятельствах? Jail это нечто близкое к пространствам имён линукса. Одно из наиболее известных применений пространств имён линукса - докер.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (-), 03-Апр-26, 00:50
	>>Когда именно? При каких обстоятельствах? > Jail это нечто близкое к пространствам имён линукса. Одно из наиболее известных > применений пространств имён линукса - докер. Исторически Jails были вроде даже раньше. Но они в результате так и остались chroot на стероидах, а namespaces доразвились сильно за эти пределы. Потом сабжи схватились за голову и что-то где-то как-то стали пытаться догонять но к тому моменту поезд уже давно ушел.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним83 (?), 01-Апр-26, 23:33
	Стоит много где, работает с редкими проблемами, меньше чем в вендах уж точно :)
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	109. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (108), 02-Апр-26, 16:37
	> Стоит много где Где именно?
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от OpenEcho (?), 02-Апр-26, 19:32
	pfSense, OpnSense, Netflix, WhatsApp, Sony, NetApp, Juniper Networks...
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним83 (?), 02-Апр-26, 23:23
	У меня лично и у клиентов конторы где я сейчас.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	131. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (-), 03-Апр-26, 00:53
	> У меня лично и у клиентов конторы где я сейчас. "Я и моя ср@ная кошка. Нет, целых две ср@ных кошки, обломайтесь!" А так да, прикольное соседство - наиболее мерзкие, жадные, некооперативные и токсичные корпы юзают сабж. Просто потому что там - делиться не надо. За что сабж и пребывает в характерном состоянии, сожраный eParasites изнутри...
	Ответить | Правка | Наверх | Cообщить модератору

5. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
Сообщение от Аноним (8), 01-Апр-26, 14:44
> при проверке подписи данные из пакета копируются в фиксированный буфер без должной проверки соответствия размера. Прям как диды в 4̶5̶м̶ unix4! Потомки держат марку и продолжают упорно делать одни и те же ошибки. Такое упорство (и упоротость) внушает уважение.
Ответить | Правка | Наверх | Cообщить модератору

	19. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (19), 01-Апр-26, 15:10
	> Потомки держат марку и продолжают упорно делать одни и те же ошибки. Причем уже шестой десяток к ряду. За это время иные люди успели родиться, жениться, вырастить детей, понянчить внуков и отправиться на тот свет. А сишочники все за буферы вылазят. П - прогресс.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от Аноним83 (?), 01-Апр-26, 23:54
	Да да, вот именно что и сами выросли, выучились и детей завели, выучили и тп. А вы только о каком то там коде думаете и каких то ошибках в нём. Между тем С код как работал выполняя полезную работу так и дальше работает, если бы это было не так  - он был бы на свалке истории уже очень и очень давно. Ну и так чтобы совсем: годов до 2010 и выбора то особо не было: или у тебя С код который иногда падает или ничего/всё очень тормозное. Можно было накодить mp3 декодер или zip архиватор хоть на бейсике, но пользоватся этим никто в здравом уме не стал - это показала история. История же показала что даже макромедиа флеш плеер у которого каждую неделю находили по 2-3 зиродея с зирокликами и выполнением кода оставался самым популярным и мастхэв плагином для браузера как минимум года 3-4 пока макромедия не похоронила проект. Это я к тому что вы конченные психи и 60 лет было только в ваших фантазиях, а реально лет 10-15 как активно борятся с програмными вандалами которые поставили на коммерческие рельсы эксплуатацию программных деффектов.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от Аноним (88), 02-Апр-26, 00:22
	> Да да, вот именно что и сами выросли, выучились и детей завели, выучили и тп. Точно выучились? > А вы только о каком то там коде думаете и каких то ошибках в нём. Это моя работа, о коде думать в рабочее время. > Между тем С код как работал выполняя полезную работу так и дальше работает, если бы это было не так  - он был бы на свалке истории уже очень и очень давно. Он уже одной ногой на свалке истории. Компиляторы? С++, желательно современный. На дыряхе компилятор не напишешь, даже GCC сдался. Бизнес приложения? Джава. Винда? Си-шарп. Андроид? Колин. Яблоко? Свифт. Вебня? TS. Что осталось? Ядро и древние утилиты и либы? Ну так их уже постепенно заменяют на современные языки. Зиг, раст и тд > Это я к тому что вы конченные психи А может ты просто e##нат? > и 60 лет было только в ваших фантазиях, Первый СИшный дрмокод был вот прямо в юникс4) > а реально лет 10-15 как активно борятся с програмными вандалами которые поставили на коммерческие рельсы Хакерские атаки массово начались с распространения интернета. Это было не 10-15 лет назад, а все 25+. > эксплуатацию программных  деффектов. Возможно дело таки в дефектных пограммистах, которые привыкли бракоделить?
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним83 (?), 02-Апр-26, 00:38
	> Он уже одной ногой на свалке истории. Да да. До сих пор открываешь что MSDN что man от линуха/бсд и там все функции про сишный код и примеры на С. Берёшь библиотеку а она или С или реже С++ или какая то ненужная муйня а то и просто биндинг к С либам. > Хакерские атаки массово начались с распространения интернета. Они не были ни массовыми ни коммерческими. ILoveYou, CodeRed прокатились массово в начале 200х, но это было ради лулзов или мелкой мести, как и всё что я встречал в те годы в VBA макросах и прочем где можно было видеть исходники. > Ну так их уже постепенно заменяют на современные языки. Как звучит! А давайте ещё русский, английский, китаский тоже заменим на современные языкими, а то они совсем старые :) Зачем - ну ради современности конечно, а то общаемся на каком то старье.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (112), 02-Апр-26, 01:39
	>ILoveYou, CodeRed прокатились массово в начале 200х Про червь Морриса из 1988 вы ничего не слышали?
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–2 +/–
	Сообщение от Аноним83 (?), 02-Апр-26, 02:06
	Я же написал: массово если и случалось то ради лулзов. Читай приносило скорее неудобства.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (112), 02-Апр-26, 13:49
	>Читай приносило скорее неудобства. В википедии утверждается, что ущерб был в 96,5 миллионов долларов. Хватит выкручиваться, просто признайте свою неправоту.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним83 (?), 02-Апр-26, 23:25
	Читайте дальше совецкие википедии. Этот ущерб кто, как и для кого считал то? И потом на фоне размеров мировой экономики это ниобчём, даже на фоне бюджета одного штата.
	Ответить | Правка | Наверх | Cообщить модератору

	118. Скрыто модератором	+/–
	Сообщение от Аноним (118), 02-Апр-26, 20:19
	>С++, желательно современный LLVM/clang. Тот самый, без которого смузиязычки не компилятся поныне.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	92. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (112), 02-Апр-26, 01:37
	>А вы только о каком то там коде думаете и каких то ошибках в нём. Вы так говорите, словно одно исключает второе. >Ну и так чтобы совсем: годов до 2010 и выбора то особо не было Выбор есть всегда. Проблема не в том, чтобы создать язык который лучше си, проблема в том, чтобы на этом языке писал не только автор. И единственный яызк, у которого это получилось - довольно посредственный раст. >или у тебя С код который иногда падает Не лгите. Код на си падает далеко не всегда, гораздо чаще он просто портит память. >или ничего/всё очень тормозное. Для подавляющего количества софта уровня условного go/ocaml/sml более чем хватит. >Это я к тому что вы конченные психи и 60 лет было только в ваших фантазиях, а реально лет 10-15 Вы мягко говоря лжёте. ATS появился в 2006, Cyclone в 2001. С учётом того, что определённые вещи, вроде нулевых указателей, починены ещё в SML разработка когорого началась в 1980-ых, времени на починку было гораздо больше. >с програмными вандалами Ха, ха, ха. А если программа просто падает, от того, что пользователь мышкой пошевелит, это что, хорошо по вашему?
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	96. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от Аноним83 (?), 02-Апр-26, 02:38
	> Ха, ха, ха. А если программа просто падает, от того, что пользователь мышкой пошевелит, это что, хорошо по вашему? Это бывало не удобно. Но меня вполне устраивает ситуация когда в типичной работе сбоев не возникает, и я и сам прилагал усилия в починке того что падало при обычной работе. То что сейчас кое как находят какие то комбинации не встречающиеся в дикой природе от которых оно падает или делает не то - это мягко говоря массам не интересно. > Код на си падает далеко не всегда, гораздо чаще он просто портит память. Если это не приводит ни к каким негативным последствиям - то пофик. > Для подавляющего количества софта уровня условного go/ocaml/sml более чем хватит. Удачи вам поиграть, послушать музыку, посмотреть кино, сделать архив на этих ваших не С/асм языках. Даже сейчас, поди и 1080 не осилят банальный деинтерлейс делать на 25 фпс. > Вы мягко говоря лжёте. ATS появился в 2006, Cyclone в 2001. С учётом того, что определённые вещи, вроде нулевых указателей, починены ещё в SML разработка когорого началась в 1980-ых, времени на починку было гораздо больше. Никогда про них не слышал. Но если они хотя бы на 5-10% медленее С - они были даром не нужны ни в 2006 ни тем более раньше. Ещё раз: основной проблемой до коры дуба или даже ещё +10 лет после была производительность. Не колебало никого что там нечто дырявое или упасть может, потому что выбора не было: или у тебя дырявый и падучий флеш плеер или ты сидишь без игор и видосиков. А до того или у тебя вин95/98 который может упасть от движения мышки или ничего. А разница между какимнить алгоритмом сжатия написанном на вижалбейсике и С была в десятки-сотни раз по скорости. Более того, в эпоху первопней и только появившегося ммх в пень2 даже банальный мп3 послушать - это был state of art код на асме. Ещё была тема с тем что ОЗУ было мало и оно было дорогое. В том же 2008 году ноуты в среднем/бюджетном секторе продавали с 512мб-1г оперативы, и модерновая виста в которой поперписывали многое на шарпе/нете там кое как ворочилось, на 1-2 ядерном проце. А до того и 128-256мб оперативы считалось уже много. Не было места и денег на все эти излишества которым сейчас предаётся индустрия. Ни один другой язык кроме С не взлетел в этой нише - потому что не был достаточно хорошим по своим потребительским свойствам, так проголосовал рынок и конечных потребителей и производителей и экспертов индустрии. Если всё ещё что то не понятно: садитесь за пень1-пень2, посидите там с месяц и подумайте о смысле сущего. Будет совсем замечательно если вы там свой любимый раст запустите и попробуете собрать что то - как раз год пролетит незаметно.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (112), 02-Апр-26, 13:40
	>Это бывало не удобно. Какая обтекаемая формулировка "бывает неудобно". >Но меня вполне устраивает ситуация когда в типичной работе сбоев не возникает Нет никакой типичной работы. Когда игра падает на каком-то уровне, и падает стабильно, то пройти эту игру невозможно. И то, что игра падает на своём же уровне, и не даёт эксплуатируемой уязвимости, игроку абсолютно никак не помогает. >Если это не приводит ни к каким негативным последствиям - то пофик. Любая проча памяти - это негативное последствие. >Удачи вам поиграть, послушать музыку, посмотреть кино, сделать архив на этих ваших не С/асм языках. Производительности условного pygame более чем достаточно для большого количества игр. Если производительности языка не хватает, то достаточно вынести только движок на си, всё остальное делать на чём-то более высокоуровневом. Современные игры зачастую поступают именно так, вместо того, чтобы писать игру целиком на си. Архиваторам не требуется фиксированное время отклика, и реализация не на си будет вполне рабочей. >Никогда про них не слышал. Вы уже услышали о них от меня. Если вы почитаете предыдущие темы, то там эти языки тоже упоминаются. Ваша позиция черезычайно удобная, можно всегда говорить, что слышите впервые, даже лет двадцать спустя. >Но если они хотя бы на 5-10% медленее С - они были даром не нужны ни в 2006 ни тем более раньше. Нет никакой "производительности си". Вот вышла первая версия программы, в которой происходит выход за границу массива, поскольку программист забыл написать проверку. Программист обнаружил проблему, и воткнул проверку, выпустил новую версию, в которой производительность от этой единственной проверки взяла и упала. Какая из этих программ имеет "произвдительности си", а какая - не имеет? >Не колебало никого что там нечто дырявое или упасть может, потому что выбора не было: или у тебя дырявый и падучий флеш плеер или ты сидишь без игор и видосиков. В ваших словах уже есть противоречие. Флеш плеер загружал не бинарный код x86, а высокоуровневый код на ActionScript. Уже тогда, игры не писались на си. И вопросы, какие возникали, возникали не к ActionScript, а к среде выполнения. И когда за несколько лет в этой среде выполнения накапливалось какое-то количество исправлений, никто не ныл, что код от этого становился медленнее. Вот если бы флеш плеер был бы компилятором си, плюс библиотеками времени выполнения, то тогда ваши слова имели бы смысл. >А разница между какимнить алгоритмом сжатия написанном на вижалбейсике и С была в десятки-сотни раз по скорости. На каком основании вы приравниваете визуал бейсик, с динамической типизацией, упакованными переменными и автоматическим управлением памяти и Сyclone и ATS где было ручное управление памятью и работа без прослоек? >В том же 2008 году ноуты в среднем/бюджетном секторе продавали с 512мб-1г оперативы, и модерновая виста в которой поперписывали многое на шарпе/нете там кое как ворочилось, на 1-2 ядерном проце. Вы опять рассказываете сказки. На нормальном, пускай и дешёвом ноутбуке, от замены висты на xp, производительность ниоткуда чудесным образом не появлялась. Поскольку у ноутбука были ресурсы на висту изначально. >А до того и 128-256мб оперативы считалось уже много. Проблемы были как раз у тех, кто пытался засунуть висту в такие устройства. >Ни один другой язык кроме С не взлетел в этой нише - потому что не был достаточно хорошим по своим потребительским свойствам Вы некомпетентны, чтобы рассуждать об этом. Я вам уже сказал, что ни ATS, ни Cyclone не требовали каких-то дополнительных абстракций, которые будут потреблять ресурсы во время выполнения, по сравнению с си. >Если всё ещё что то не понятно: садитесь за пень1-пень2, посидите там с месяц и подумайте о смысле сущего. Пользование первого пунтиума не даёт вам ни малейшего права рассуждать о том, что этот самый пентиум тянет, а что нет. Когда в код добавляется проверка на выход за границы массива, системные требования не перескакивают с первого пентиума на второй пентиум. >если вы там свой любимый раст запустите При чём здесь раст? Я вам про Cyclone и ATS пишу, а вы про раст мне рассказываете. Вы на первопне современный gcc запустите и поделитесь успехами. Сейчас вполне обычный gcc может потреблять более гигабайта, без всякого раста. Засунете это в 128 Мб?
	Ответить | Правка | Наверх | Cообщить модератору

	126. Скрыто модератором	+/–
	Сообщение от Аноним83 (?), 02-Апр-26, 23:40
	> Нет никакой типичной работы. Говорите за себя. > Любая проча памяти - это негативное последствие. Только для фонатиков. Для нормальных людей важен результат работы программы а не её внутреннее состояние. > Современные игры зачастую поступают именно так, вместо того, чтобы писать игру целиком на си. И требуют бугагерцов, 100500 ядер и 1000050000 памяти. Речь то шла про эпоху до коредуо, когда весь софт писали на С ради того чтобы оно хоть как то работало. > Архиваторам не требуется фиксированное время отклика, и реализация не на си будет вполне рабочей. Да, конечно, так и есть. Удачи вам в использовании архиваторов на питоне без примеси С кода. > Вы уже услышали о них от меня. Я не трачу время на пробу всякого бесполезного булщита. > Нет никакой "производительности си". Таки есть. В былые времена даже ужасно написанный код на С был быстрее всех прочих. > Флеш плеер загружал не бинарный код x86, а высокоуровневый код на ActionScript. Флеш плеер был написан на С/С++ и являлся самым дырявым и эксплуатируемым реально зловредами компонентом сотен миллионов систем на протяжении 3+ лет. Это знали вообще все, даже тупые пользователи. Это никого не останавливало от использования. > На каком основании вы приравниваете визуал бейсик На том основании что я на нём писал очень много когда то и знаю не по наслышке насколько оно медленее и неудобнее в плане использования винапи по сравнению с С/С++. Про ваш циклон никто тогда слыхом не слыхивал, и всем очень повезло не иметь с ним дело - технология не получила распространия, все сэкономили на это время и деньги кто не вляпался. > На нормальном, пускай и дешёвом ноутбуке, от замены висты на xp, производительность ниоткуда чудесным образом не появлялась. Поскольку у ноутбука были ресурсы на висту изначально. Чувак, ты реально такой молодой и не застал говнобуки куда кое как вкорячили висту? > Я вам про Cyclone и ATS пишу, а вы про раст мне рассказываете. Это всё какая то маргинальщина ещё больше раста, которая не взлетела тогда и сейчас никому не нужна.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (112), 03-Апр-26, 11:43
	>Для нормальных людей важен результат работы программы а не её внутреннее состояние. Программа с повреждённым внутренним состоянием правильно работать не будет. >И требуют бугагерцов, 100500 ядер и 1000050000 памяти. >Речь то шла про эпоху до коредуо, когда весь софт писали на С ради того чтобы оно хоть как то работало. Вы опять фантазируете. Условному платформеру на pygame это всё не требуется. Если брать условный golang/ocaml/sml, то потребуется ещё меньше ресурсов, чем на pygame. >Удачи вам в использовании архиваторов на питоне без примеси С кода. Вы как-то резко переключились на питон. Во-первых, все языки, которые я упомянул, собираются в двоичный код. Во-вторых, разница по времени между сишными архиваторами, с разными алгоритмами сжатия достаточно велика, и когда один архиватор сжимает за несколько секунд, второй будет сжимать несколько минут, и для больших файлов, которые нужно по-быстрому передать по сети, данный вариант будет неприемлим. >В былые времена даже ужасно написанный код на С был быстрее всех прочих. Вы опустили весьма важный вопрос: у какой программы на си настроящая производительности си - с проверкой на выход за границы массива, или без неё? >Это никого не останавливало от использования. Останавливало. Кто-то выкачивал видео скриптами. Кто-то ушёл на html5 сразу же, как тот появился. >На том основании что я на нём писал очень много когда то и знаю не по наслышке насколько оно медленее и неудобнее в плане использования винапи по сравнению с С/С++. Для того, чтобы сравнивать два языка, нужно разбиратся сразу в двух языках. Вы про Cyclone и ATS не знаете ровным счётом ничего. Вы как застряли на уровне визуал бейсика в девяностых, так далее и не продвинулись. >Чувак, ты реально такой молодой и не застал говнобуки куда кое как вкорячили висту? У меня был самый дешёвый, из тех что были в магазине, ноутбук с вистой. И после установки туда что семёрки, что xp, производительность ниоткуда волшебным образом не появилась.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	106. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (112), 02-Апр-26, 13:57
	>Никогда про них не слышал. Упоминание ATS даже на этом же форуме за 2019 https://www.opennet.ru/opennews/art.shtml?num=52081#92 2014 https://www.opennet.ru/opennews/art.shtml?num=40035#15 2013 https://www.opennet.ru/opennews/art.shtml?num=38621#5 Мне лень искать более ранние упоминания, так что узнать об этом языке можно было уже давным давно.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	98. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (-), 02-Апр-26, 07:24
	> Вы мягко говоря лжёте. ATS появился в 2006, Cyclone в 2001. С > учётом того, что определённые вещи, вроде нулевых указателей, починены ещё в > SML разработка когорого началась в 1980-ых, времени на починку было гораздо больше. Проблема только в том что на отшибленых брейнфаках, да еще с проприетарским душком и за много денег - програмить почему-то никто не хочет. А для тех кто на бронепоезде - софт должен хотя-бы работать для начала. А потом можно попробовать заняться улучшением его свойств. Все ваши ATS и Cyclone не доехали даже до первой части марлезонского балета. А все остальное после этого уже и не важно...
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	104. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от Аноним (112), 02-Апр-26, 13:43
	>на отшибленых брейнфаках, да еще с проприетарским душком и за много денег Вы выдаёте свою фантазию за реальность.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (-), 03-Апр-26, 00:54
	>>на отшибленых брейнфаках, да еще с проприетарским душком и за много денег > Вы выдаёте свою фантазию за реальность. Прикольная проекция, но кажется это все же делаю не я...
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (118), 02-Апр-26, 20:16
	Код на C и C++ выполняет задачи - пока другие все никак не осилят собственный компилятор.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

9. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
Сообщение от Аноним (9), 01-Апр-26, 14:51
В gentoo не воспроизвелось. Vim версии 9.1.1652, вроде бы должен быть подвержен, ибо Affected versions > 9.1.1390 && < 9.2.0172
Ответить | Правка | Наверх | Cообщить модератору

	39. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (39), 01-Апр-26, 16:28
	Ты удивишся, но в Slackware Linux тоже некоторые уязвимости не работают. Сам замечал. Почему так? Не знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+3 +/–
	Сообщение от Аноним (81), 01-Апр-26, 23:35
	> некоторые уязвимости не работают И не только уязвимости.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (9), 03-Апр-26, 10:12
	не про gentoo тут у меня "тейк", но про версию вима. Если для "уязвимости" требуется специальная настройка вима, то хотелось бы знать, какая. Насколько она осмысленная, возможно ли обнаружить такой вим у кого-либо. Но в целом я ожидал другой вид атаки на vim - через зависимости питоновского кода в редакторе. Совершенно ненужная зависимость как в vim так и в gdb.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

11. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
Сообщение от Аноним (-), 01-Апр-26, 14:53
> сводились к примитивной постановке задачи, такой как "найди 0-day уязвимость в Vim, возникающую при открытии файла". В итоге модель Claude успешно нашла ранее не известные уязвимости. Кто там в темах про "AI проверка в ядре" куракекал "Не нужон ваш ЫЫ!" ? Что теперь скажите? Тыщи глаз проблему не видели годами.
Ответить | Правка | Наверх | Cообщить модератору

	14. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (14), 01-Апр-26, 14:59
	Почитай, что ещё может сделать modeline, и пойми, что те кто шарят выключали его и так сразу. Раньше у этой фичи и песочницы не было никакой, просто проект оброс фичами и про modeline забыли.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от Аноним (62), 01-Апр-26, 19:40
	> Кто там в темах про "AI проверка в ядре" куракекал "Не нужон ваш ЫЫ!" ? Ты в недалёком будущем. Когда шеф скажет: "мне тут ИИ нашептал что ты мало работаешь, да и вообще можно тебя уволить..."
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	110. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (108), 02-Апр-26, 16:44
	Зачем ждать это недалёкое будущее? Я этот шеф, сегодня, сейчас. ИИ роет джиру, гитхаб, пару внутренних систем, и показывает мне с достаточной точностью кто работает, и как усердно, а кто бакланит. На первый раз с бакланом был серьёзный™ разговор™ за закрытой дверью. На второй буду отчитывать публично на стендапе. На третий пойдёт куда-нибудь из моей команды в другую, а то и вовсе на выход. Мне бездельники не нужны, я не хочу вечно сидеть менеджером нижнего звена.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от нах. (?), 02-Апр-26, 20:38
	Когда у тебя от команды останутся только деятельные иди0ты, обожающие слежку  и публичные порки - тебя безусловно повысят до менеджера среднего звена. В дерьмовых компаниях обычно именно так и повышают. (потому что это там единственный способ избавиться от человека, развалившего команду) И да, если ты не в курсе без всякого ыы, чем у тебя занимаются сотрудники, и не можешь вовремя и без негативной реакции вмешаться - выгнать нахрен следует именно тебя.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (108), 03-Апр-26, 02:12
	Забыл спросить исполнителя, как его удобнее кнутовать. Без "всякого ыы" у меня бы точно не хватило терпения копаться, но раз уж выяснилось, что все в команде без исключению работают минимум 4 часа в день, и только один василий решил, что он особенный и может уделять работе не больше часа, тут без негативной реакции никак. Будь он умным и сделай всё в срок я бы даже бровью не повёл. Но теперь из-за него я плохо выгляжу в эксельке моего начальника, а это недопустимо. Вот и как тут без негативной реакции?
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 03-Апр-26, 09:17
	ну я и говорю - дерьмо ты, получается, а не руководитель. И да, бывает что вот такой работающий по часу в день тянет на себе не то чтобы больше чем рабы пашущие по девять, если сравнивать в количестве строчек, но после его ухода все внезапно становится еще хуже. История Генри Форда как бы намекает нам... > Но теперь из-за него я плохо выгляжу в эксельке моего начальника, а это недопустимо. это ты из-за себя плохо выглядишь - потому что неправильно согласовал время на выполнение задач. Но для этого и не нужен был ЫЫ. Нужно было уметь правильно оценить трудозатраты и не забыть умножить на 2.5 для тривиальных задач, и на 10 для архитектурных. Линейный руководитель обязан уметь это делать без подсказок ыы, потому что сам является одним из исполнителей и по крайней мере в теории может подменить любого (вероятно неэффективно и не лучшим образом каждого, но суметь обязан), а отличает его от исполнителя именно умение просчитать общие трудозатраты - с учетом возможностей команды, а не наиболее активного раба в ней. Тот завтра выгорит и уволится. А этот вот ненапряжно работавший мог остаться, но ты его уже достал нафиг поэтому он с тем первым тоже сбежит. И ты будешь еще более хреново выглядеть в эксельке. Поэтому повышение - единственный способ спасти проект от таких руководителей.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (75), 01-Апр-26, 23:08
	А ты тут с какого боку?
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

13. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
Сообщение от Аноним (14), 01-Апр-26, 14:57
modeline само по себе сомнительная фича, которая включаться должна опционально. Хз зачем её выставили по дефолту в включенное состояние.
Ответить | Правка | Наверх | Cообщить модератору

15. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
Сообщение от Фонтимос (?), 01-Апр-26, 15:00
Сегодня день антрофика или первое апреля? > "найди 0-day уязвимость в Vim, возникающую при открытии файла" пошел заставлять клод сделать: "найди любую уязвимость в ядре линукса при загрузке и сделай мне эксплойт"
Ответить | Правка | Наверх | Cообщить модератору

16. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
Сообщение от bOOster (ok), 01-Апр-26, 15:04
Не жилось спокойно c Heimdal, потянули это гавno в базу - MIT kerberos. И да, причем тут FreeBSD? Ее пользовать можно с Heimdal.
Ответить | Правка | Наверх | Cообщить модератору

17. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–6 +/–
Сообщение от Аноним (19), 01-Апр-26, 15:07
> Удалённо эксплуатируемые уязвимости в ядре FreeBSD > Проблема вызвана тем, что при проверке подписи данные из пакета копируются в фиксированный буфер без должной проверки соответствия размера. Ну кто бы сомневался... Шел шестой десяток лет наступания на одни и те же грабли. > Уязвимость была выявлена [...] при помощи AI-ассистента Claude. "Статические анализаторы решают все проблемы", говорили они. "Галлюцинирующий ИИ для этого нинужон", говорили они. > использовав Claude для выявления уязвимостей в Vim и Emacs, позволяющих добиться выполнения своего кода > промпты к модели сводились к примитивной постановке задачи, такой как "найди 0-day уязвимость в Vim, возникающую при открытии файла". В итоге модель Claude успешно нашла ранее не известные уязвимости. Поздравляю всех сишочных бракоделов: теперь буквально любой васян, даже в глаза не видевший программирования, может ломануть систему, в которой есть наовняканый вами код. А ИИшка для этого ему не только дырочки найдет, но и даже всю структуру для взлома засетапит. Слава богу, хоть развитие ИИ наконец-то положит конец этим десятилетиям халатного бракодельства на недоязыке из 70х. Ибо сколько уже это можно терпеть?
Ответить | Правка | Наверх | Cообщить модератору

	20. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от bOOster (ok), 01-Апр-26, 15:12
	Ты со свечкой что-ли стоял - когда ИИ уязвимость искал? Очередной бред для придурков видящих в лжеИИ панацею от всех болезней.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+4 +/–
	Сообщение от Аноним (24), 01-Апр-26, 15:25
	> Очередной бред для придурков видящих в лжеИИ панацею ИИ баг нашел bOOster баг не нашел. И кто из вас таки идийот?))
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–2 +/–
	Сообщение от bOOster (ok), 01-Апр-26, 15:46
	Конечно же ты, такой большой.. Такой толстый... А в сказки веришь...
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (-), 01-Апр-26, 16:44
	>  Конечно же ты, такой большой.. Такой толстый... А в сказки веришь... Это ты - деволюционировал куда-то обратно на ветки деревьев. Я буквально вчера починил реальный баг отрепорченый AI. А у тебя будущее все так и не наступило. Как-как, говорите, объекты тяжелее воздуха - летать не могут?! Надо рассказать пилотам что их не существует.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (108), 02-Апр-26, 16:45
	Сказки или нет, а ты баг не нашёл.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	31. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (31), 01-Апр-26, 15:47
	>И кто из вас таки идийот?)) Очень похоже на рекламную многоходовку. 1)Люди находят багу 2)Пишем разгромную статью про преслести нашего ЫЫ 3)идийоты покупаются пачками Для проверки теории, сам попроси твой любимый ЫЫ найти тебе 0-day дыру где нибудь, и эксплойт написать. А потом расскажи нам, что у тебя получилось.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	55. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (19), 01-Апр-26, 18:30
	> Очень похоже на рекламную многоходовку. > 1)Люди находят багу > 2)Пишем разгромную статью про преслести нашего ЫЫ Нет, это похоже на копиум любителей торий заговоров. Других объяснений неудобным фактам вы не допускаете, чтобы не рушить свою уютную картину мира. Это стадия отрицания. Это пройдет.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (56), 01-Апр-26, 18:40
	Если бы это не было рекалмой ЫЫ, то фиг бы упомянули про ЫЫ, взали бы на себя все лавры. Тут же классическое рекламное гонево, даже слог соответствующий
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (19), 01-Апр-26, 19:40
	> Если бы это не было рекалмой ЫЫ, то фиг бы упомянули про ЫЫ, взали бы на себя все лавры. Чего вдруг? Лавры статических анализаторов и прочих валгриндов никто себе не присваивает. > Тут же классическое рекламное гонево, даже слог соответствующий В патче кроме "Credits: Nicholas Carlini using Claude, Anthropic" об ИИ ни слова. https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08... Причем упоминание факта использования ИИ - это нынче обычное требование в большинстве проектов, включая Linux: https://docs.kernel.org/process/coding-assistants.html
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 02-Апр-26, 20:59
	> В патче кроме "Credits: Nicholas Carlini using Claude, Anthropic" об ИИ ни слова. Так это и не патч, это pr. И это и есть стандартный шаблон которым клава помечает полностью ей написанные pr'ы. (Да, она и пальцы за тебя сама загибать будет - уж чо-чо, а чисто механически оформить сообщение вполне для робота работенка.) Патч вот он: https://cgit.freebsd.org/src/commit/?id=143293c14f8de00c6d3d... (осторожно, анубисо-помойка) и его автор Mark Johnston <markj@FreeBSD.org> - Claude сама ничего не патчила, только сообщила о проблеме. Мне, кстати, пришлось дать ей дополнительного пинка чтобы она НЕ подписывала мной не мной написанный код (причем там похоже очень жестко прописан этот промпт, или это вообще не промпт а захардкоженный скрипт, там их есть, она все время пытается вернуться к этому стилю) Иначе там будешь ты автором, с отдельной строчкой Co-Authored-By: claude, даже если ты на этот код вообще не смотрел.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–2 +/–
	Сообщение от Аноним (31), 01-Апр-26, 18:44
	>Это стадия отрицания. Это пройдет. Нельзя доказать отсутствие чего то. Но я предложил эксперимент. И отсутсвие твоих результатов как бы намекает. Но если тебе приятно думать, что у меня отрицание, то я конечно не стану лишать тебя сладкого.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	58. Скрыто модератором	+2 +/–
	Сообщение от Аноним (58), 01-Апр-26, 18:52
	> Но я предложил эксперимент. Ты слился "до сперва добейся"? Реально думаешь, что кто-то купится на такой вброс?))
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (19), 01-Апр-26, 19:43
	> Нельзя доказать отсутствие чего то. С фига ли? > Но я предложил эксперимент. И отсутсвие твоих результатов как бы намекает. Нет, раз ты утверждаешь, что это реклама и сговор - тебе это и доказывать. Бремя доказательства лежит на утверждающем - слышал такое?
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	70. Скрыто модератором	–1 +/–
	Сообщение от Аноним (31), 01-Апр-26, 20:08
	>Ты слился "до сперва добейся"? Реально думаешь, что кто-то купится на такой вброс?)) Cперва добейся, это если бы можно было подумать, что ты сам можешь найти уязвимость. Но на это ни кто не рассчитывал, от тебя требовалось просто задать вопрос ЫЫхе, которую ты так пиаришь. Если ты "Gросто задать вопрос", считаешь достижением, то тебя даже не слить, сливать нечего.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	78. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (75), 01-Апр-26, 23:11
	Про копиум рассуждать может даже ИИ на подкроватном сервере с б/у-шной видеокартой. Ты уязвимость найди, как тебе предложили.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	137. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 03-Апр-26, 10:45
	> Ты уязвимость найди, как тебе предложили. не вижу перевода с твоего криптокофелефефька. (в отличие от сотрудников антропика, у остальных токены - платные)
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (19), 01-Апр-26, 19:45
	> бред для [...] видящих в лжеИИ панацею от всех болезней. А речь и не идет про "все болезни". Речь идет конкретно о типичных сишных дыренях.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

18. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–3 +/–
Сообщение от Аноним (18), 01-Апр-26, 15:08
FreeBSD надо на дырясте переписать. FFMpeg, вон, переходит уже. "FFmpeg is moving to Rust Our use of C and Assembly in FFmpeg has been an unacceptable violation of safety. FFmpeg will be running 10x slower - but we're doing it for your safety. All your videos will appear green - safety first, working software later."
Ответить | Правка | Наверх | Cообщить модератору

	22. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+3 +/–
	Сообщение от пох. (?), 01-Апр-26, 15:19
	> FreeBSD надо на дырясте переписать. FFMpeg, вон, переходит уже. НАЧАТЬ переписывать! > All your videos will appear green - safety first, working software later." Вот! Чуваки правильно понимают фишку!
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (25), 01-Апр-26, 15:27
	Первоапрельский наброс сразу видно. "FFmpeg will be running 10x slower" Но возможно если на расте будут писать чуваки у которых с десяток CVE 10.0 и которые до сих пор пишут подобное CVE-2024-22860 - CVSS score 9.8 - FFmpeg jpegxl_anim_read_packet Integer Overflow Remote Code Execution Vulnerability Integer overflow vulnerability in FFmpeg before n6.1, allows remote attackers to execute arbitrary code via the jpegxl_anim_read_packet component in the JPEG XL Animation decoder. То да, такие уни-калы могут и раст умудриться замедлить в 10 раз.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	134. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (134), 03-Апр-26, 09:06
	На дырясте только начали корябать что-то (даже собственный компилятор не осилили) - и тут же то рута подарят, то одно, то другое.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (143), 03-Апр-26, 17:15
	> (даже собственный компилятор не осилили) Опять Войны Сyпрoтив Раста совсем не палятся ...
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
	Сообщение от Аноним (-), 01-Апр-26, 16:56
	> All your videos will appear green - safety first, working software later." Finally! All videos are Safe For Work. Safety everywhere!
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	79. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (75), 01-Апр-26, 23:12
	Да, спасибо, что напомнил на календарь посмотреть.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	100. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Проходил мимо (?), 02-Апр-26, 08:39
	Технически достаточно медленный код на Rust получается, когда компилируешь программу в режиме debug, так как там встраивается куча разного рода проверок. Если же компиляция идет в режиме release то все летает. Естественно, что многое еще зависит от реализации алгоритма, но, в целом, скорость кода на Rust сопоставима со скоростью кода на Си.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	119. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (118), 02-Апр-26, 20:27
	У дыряста нет своего компилятора, они используют сишный LLVM, в котором кодогенерация и сворачивание AST сделаны по-человечески.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (143), 03-Апр-26, 17:18
	> сишный LLVM, > сворачивание AST Зашкаливающий уровень знаний, ога. Ну тогда и сишочники свой собственнй компилятор не осилили - GCC и LLVM, внезапно, на плюсах (а в GCC конкретно еще и разновидность лиспов для высокоуровневых оптимизайий) ...
	Ответить | Правка | Наверх | Cообщить модератору

27. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
Сообщение от Сладкая булочка (?), 01-Апр-26, 15:34
> Уязвимость в Emacs вызвана автоматической обработкой содержимого каталога .git/, когда он размещён в одном каталоге с открываемым файлом. В этом случае Emacs при открытии файла запускает команды "git ls-files" и "git status", выполняемые в контексте содержимого ".git/". Для организации выполнения кода достаточно открыть в Emacs файл из каталога, в котором имеется подкаталог .git/ с файлом конфигурации "config", включающим опцию "core.fsmonitor" с указанной атакующим командой для запуска. Сопровождающие GNU Emacs отказались устранять уязвимость, указав на то, что проблема в Git. Ну то есть уязивмости в Emacs нет по факту. Почему тогда заголовок не поправлен?
Ответить | Правка | Наверх | Cообщить модератору

	35. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (35), 01-Апр-26, 15:53
	На самом деле потому что у разрабов емакс руки не из того места.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (49), 01-Апр-26, 17:07
	Ну да, они же должны были накостылять вокруг, чтоб обойти уязвимость. Но реальная уязмимость-то, всё равно, останется в Git.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 02-Апр-26, 21:04
	угу, если завтра emacs вздумает выполнить rm -rf / - это уязвимость в rm. emacs только разместил объяву. Если я открываю файл - я совершенно не обязан угадывать что эта гнутая поделка собралась выполнить пару совершенно непрошенных команд мимоходом. (Я и .git-то в этом каталоге мог не видеть, потому что и не собирался в него заглядывать и вообще искать скрытые файлы - меня интересовал конкретный файлик с вполне безопасным для редактирования содержимым.) Блин, да та же claude никогда не будет выполнять git'овые команды не спросив у тебя разрешения, хотя ей-то по должности положено ими пользоваться.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (112), 02-Апр-26, 22:00
	>если завтра emacs вздумает выполнить rm -rf / - это уязвимость в rm У вас с логикой проблемы. Emacs вызывает git, и уже git вызывает данную команду. Кроме emacs-а git может вызывать кто угодно - например какаой-то плагин zsh. Отображение текущей версии - это более чем распространённая практика.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 02-Апр-26, 23:52
	> У вас с логикой проблемы. Emacs вызывает git когда его просили - открыть файл. У кого тут проблемы не то что с логикой а вообще с мозгами - я даже спрашивать не буду.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (112), 03-Апр-26, 11:27
	>когда его просили - открыть файл. Что в вашем понимании "открыть файл"? Подсветка синтаксиса нужна или нет? Автодополнение на основе lsp нужно или нет? Отображение текущей ветки гита нужно или нет? Автоформатирование нужно или нет? А если я вместо Emacs-а файл открою в vim-е, у которого есть точно такая-же интеграция? Как Emacs-еры могут почнинить vim? Я добавил отображение текущей ветки в приглашение командной строки. Emacs-еры теперь должны моё приглашение чинить?
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 03-Апр-26, 11:55
	> Что в вашем понимании "открыть файл"? ну безусловно исполнить какой-то скрипт о существовании которого ты даже предположить не мог, поскольку каталог - скрытый. > А если я вместо Emacs-а файл открою в vim-е, у которого есть точно такая-же интеграция? мой vim никаких системных команд при открытии файла не запускает. ни гитов, ни rm. Вероятно, его авторы догадывались, почему нельзя так делать - это все же инструмент в том числе системных администраторов, был такой недавно вымерший вид. В отличие кстати от emacs.
	Ответить | Правка | Наверх | Cообщить модератору

37. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+2 +/–
Сообщение от Аноним (37), 01-Апр-26, 16:10
> Уязвимость в Emacs вызвана автоматической обработкой содержимого каталога .git/ А autorun.inf он не обрабатывает автоматически?
Ответить | Правка | Наверх | Cообщить модератору

41. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–2 +/–
Сообщение от Аноним (-), 01-Апр-26, 16:40
> Во FreeBSD устранена уязвимость (CVE-2026-4747), > позволяющая через отправку сетевых пакетов к NFS-серверу > добиться выполнения кода на уровне ядра Безопасная система, все как фаны FreeBSD обещали. Хоть что-то в ней в безопасности. Например, дыра.
Ответить | Правка | Наверх | Cообщить модератору

	71. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним (71), 01-Апр-26, 21:11
	>> Проблема проявляется при использовании модуля kgssapi.ko, реализующего API RPCSEC_GSS на стороне ядра. >> RPCSEC_GSS применяется в NFS-серверах для защиты доступа к Sun RPC с использованием аутентификации на базе Kerberos >> требует возможности отправки сетевых пакетов NFS-серверу. > Безопасная система, все как фаны FreeBSD обещали. Хоть что-то в ней в безопасности. Например, дыра. Иногда полезно и дальше заголовка читать. Хотя да, конец новости тебе не понравится: > CVE-2026-33150 - обращение к памяти после её освобождения в io_uring-обработчике из библиотеки libfuse но ведь это совершенно другое, не так ли?
	Ответить | Правка | Наверх | Cообщить модератору

	74. Скрыто модератором	–1 +/–
	Сообщение от Аноним (74), 01-Апр-26, 21:52
	>> CVE-2026-33150 - обращение к памяти после её освобождения в io_uring-обработчике из библиотеки libfuse > но ведь это совершенно другое, не так ли? Ну... эту либу в БЗДю ведь не pingvin-ятники положили, не правда ли? Но проблема конечно не в БСДе, а убогих библиотеках. И языках программирования. Но тут мало что можно сделать, только порадоваться что наконец-то нашли и пофиксили.
	Ответить | Правка | Наверх | Cообщить модератору

	101. Скрыто модератором	+1 +/–
	Сообщение от Аноним (71), 02-Апр-26, 09:29
	>>> CVE-2026-33150 - обращение к памяти после её освобождения в io_uring-обработчике из библиотеки libfuse >> но ведь это совершенно другое, не так ли? > Ну... эту либу в БЗДю ведь не pingvin-ятники положили, не правда ли? А причем тут бздя - там же специально выделено: io_uring.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (-), 02-Апр-26, 07:28
	>> CVE-2026-33150 - обращение к памяти после её освобождения в io_uring- >> обработчике из библиотеки libfuse Ага, в линуксе тоже негров линчуют... хотя погодите, libfuse таки сторонний компоенент, так что все же не в Linux. И не в кернелмоде ремотно по сети, как у некоторых. Т.е. как бы фи, но по сравнению с эксплойтабельным прям по сети ремотным кернелмодом это довольно хиловато смотрится. > но ведь это совершенно другое, не так ли? По severity проблемы и векторам атак это и прада - здорово другое.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	86. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
	Сообщение от Аноним83 (?), 02-Апр-26, 00:04
	Так чтобы тот NFS поднять да ещё с GSS авторизацией - надо постараться :) Наружу это обычно не выставляют, так что никто и не парится.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

51. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
Сообщение от Аноним (112), 01-Апр-26, 17:31
>Уязвимость в Emacs >в котором имеется подкаталог .git/ с файлом конфигурации "config", включающим опцию "core.fsmonitor" с указанной атакующим командой для запуска. А Emacs тут каким боком? Уязвимость будет везде, где есть гит интеграция.
Ответить | Правка | Наверх | Cообщить модератору

52. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
Сообщение от Аноня (?), 01-Апр-26, 17:37
> Проблема присутствует в реализации API GSS (Generic Security Services), позволяющего устанавливать защищённые аутентифицированные каналы связи с сервером Как всегда, это прекрасно. Защищайса через наши дыры )
Ответить | Правка | Наверх | Cообщить модератору

54. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
Сообщение от Аноним (54), 01-Апр-26, 18:25
Это первоапрельская новость что ли? В emacs действительно не по адресу, тут должны быть уязвимы даже шелл-промпты, показывающие текущую ветку, однако - а ОТКУДА в .git/config возьмется такая настройка? Гит не клонирует config как раз из соображений безопасности.
Ответить | Правка | Наверх | Cообщить модератору

	59. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (59), 01-Апр-26, 18:56
	> а ОТКУДА в .git/config возьмется такая настройка? У любителей качать архивы с серверов.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (61), 01-Апр-26, 19:11
	У таких, наверное, и гита нет -- нечему запускаться.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 01-Апр-26, 19:44
	ты конечно же вспомнишь об этом, решив посмотреть ЧУЖОЙ файлик в чужом каталоге?
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	107. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от Аноним (112), 02-Апр-26, 15:10
	Сейчас настало то время, когда даже чужой проект нужно открывать внутри контейнера.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 03-Апр-26, 11:59
	> Сейчас настало то время, когда даже чужой проект нужно открывать внутри контейнера. чужой просто текстовый файлик. Потому что ты думаешь что это текст, а это "проект".
	Ответить | Правка | Наверх | Cообщить модератору

69. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
Сообщение от dhtscaner (?), 01-Апр-26, 20:08
если они встроят это в пайплайны, релиз не случится никогда.
Ответить | Правка | Наверх | Cообщить модератору

80. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+1 +/–
Сообщение от Аноним83 (?), 01-Апр-26, 23:30
Рекламная компания: "ИИ можит фсё! только заплати!" продолжается как я вижу. После прошлой новости когда клауда там что то якобы нашёл я решил из интереса посмотреть на это сам. На сайте клауды почему то решили что я должен обязательно верифицировать у них свой номер мобилы, помимо почты. Даже вход по гуглоакку без мобилы их не устроил. Я решил что палить такой мутной конторе даже свой мусорный номер я не стану. (если что я не под санкциями, и заплатить и верифицироватся могу, вопрос доброй воли) Потом я вспомнил что какое то ИИ есть в гитхубе, там клауда тоже оказалось что есть. Я попросил его проверить мою репу и найти там все уязвимости. Со 2-3 попытки мы примерно поняли друг друга. Как итог этот ИИ даун в отчёте написал про то что у меня было помечено как // XXX и // TODO, пару случаев где типа может переполнится size_t, и пару случаев где по мнению ИИ можно записать за пределы буфера. И конечно strcpy из забытого и закоментированного кода :) В общем ХЗ. Или за бесплатно только ИИ даунов дают погонять, или у исследователей какой то другой ИИ, который сгонял на чорный рынок, и за 4 часа купил там готовых уязвимостей у черношляпнков на деньги рекламного бюджета конторы :) Сказать что ИИ совсем плохое я не могу: гуглопоискоивый ИИ часто экономит время на простых и средних вопросах, выдавая рабочий или почти рабочий код в качестве примеров. И платный чатгпт жене гуманитарию всякие подгоны генерит вроде в тему :) Те я чото как то не верю и не жду готовых к использованию результатов от ИИ, всё надо перепроверять или переделывать за ним.
Ответить | Правка | Наверх | Cообщить модератору

102. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
Сообщение от Аноним (102), 02-Апр-26, 13:20
Вот неиронично, пользуюсь условным нотепадом и норм. Все остальное - рано или поздно проблемы.
Ответить | Правка | Наверх | Cообщить модератору

	114. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	+/–
	Сообщение от нах. (?), 02-Апр-26, 17:46
	> Вот неиронично, пользуюсь условным нотепадом и норм. если ничего кроме списка покупок в ближайшей перетерочке не писать - то и норм. А если тексты для людей или код - то очень быстро надоест. Причем даже notepad++ - уже с проблемами.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (102), 03-Апр-26, 00:12
	C, плюсы 11, Go, скрипты - полет нормальный.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Удалённо эксплуатируемые уязвимости в ядре FreeBSD, Vim и Em..."	–1 +/–
	Сообщение от Аноним (142), 03-Апр-26, 13:18
	skill issue
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

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

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