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

"Опубликованы результаты аудита безопасности кодовой базы LLVM"	+/–
Сообщение от opennews (??), 01-Мрт-24, 23:49
Фонд OSTIF (Open Source Technology Improvement Fund), созданный с целью усиления защищённости открытых проектов, объявил о завершении независимого аудита  кода проекта LLVM. Работа выполнена английской компанией Ada Logics. В ходе проведённой работы был восстановлен прерванный более года назад процесс тестирования в OSS-Fuzz. С 1.1 до 2.4 млн строк кода увеличен охват кодовой бызы, вовлечённой в fuzzing-тестирование. Также был расширен используемый для fuzzing-тестирования инструментарий, а число применяемых для проверки fuzzing-движков увеличено с 12 до 15... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60707
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	–1 +/–
Сообщение от Аноним (-), 01-Мрт-24, 23:52
> 12 новых проблем ... и ВСЕ проблемы с памятью! LLVM же на плюсах написан. А плюсы должны уметь в память, это же не сишка. Что у них пошло не так?
Ответить | Правка | Наверх | Cообщить модератору

	7. Скрыто модератором	+3 +/–
	Сообщение от Аноним (-), 02-Мрт-24, 00:14
	То что плюсы в память лучше чем сишка, не значит что они идеальны. Особенно если приходят какие-то покалеченные дыряшкой и начинаю разводить "СИ с классами" А к сожалению таких много(( Если видишь в вакансии 'знание С/С++' на 98% это очередной адепт сишных подходов который решил, что в плюсы он тоже может.
	Ответить | Правка | Наверх | Cообщить модератору

	9. Скрыто модератором	+6 +/–
	Сообщение от Аноним (9), 02-Мрт-24, 00:20
	Бла-бла-бла, теоретик херов. Ты хоть код LLVM позырь и найди там CИ с классами
	Ответить | Правка | Наверх | Cообщить модератору

	31. Скрыто модератором	+1 +/–
	Сообщение от n00by (ok), 02-Мрт-24, 08:12
	> Если видишь в вакансии 'знание С/С++' на 98% это очередной адепт сишных > подходов который решил, что в плюсы он тоже может. Скорее значит, что он толком не знает ни Си, ни Си++.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	15. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+10 +/–
	Сообщение от Bottle (?), 02-Мрт-24, 00:51
	На два миллиона строк это нереально мало. Вероятнее всего это ошибки работы с памятью, которые можно записать в логические.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	20. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+7 +/–
	Сообщение от Аноним (20), 02-Мрт-24, 01:49
	Инструмент для обнаружения ошибок памяти обнаружил... ошибки памяти. Какая неожиданность!
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	28. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+11 +/–
	Сообщение от Аноним (-), 02-Мрт-24, 03:23
	> LLVM же на плюсах написан. > А плюсы должны уметь в память, это же не сишка. Что у них пошло не так? Возможно я сделаю твой день, но вон там CVEхи с ошибками работы с памятью - даже на хрусте. Ну, вот, таки - смогли! Осилили. И ариан на безопасной аде - уронили. Ты недооцениваешь креативность двуногих, анон.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	33. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+1 +/–
	Сообщение от n00by (ok), 02-Мрт-24, 08:27
	2,4 миллиона строк на плюсах - это примерно как в 12 миллионах строках на Си было бы 12 ошибок.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	73. Скрыто модератором	+/–
	Сообщение от Аноним (-), 04-Мрт-24, 06:38
	>должны уметь в память Переведите пожалуйста ЭТО на нормальный русский язык!
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	77. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от adolfus (ok), 05-Мрт-24, 19:33
	Нет разницы, используется malloc() или его обертка в виде ключевого слова new. В обоих случаях имеем один и тот же указатель.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	78. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 06-Мрт-24, 12:25
	> Нет разницы, используется malloc() или его обертка в виде ключевого слова new. > В обоих случаях имеем один и тот же указатель. new может не вернуть указатель, а бросить std::bad_alloc.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от adolfus (ok), 15-Мрт-24, 17:00
	>> Нет разницы, используется malloc() или его обертка в виде ключевого слова new. >> В обоих случаях имеем один и тот же указатель. > new может не вернуть указатель, а бросить std::bad_alloc. Может, но внутри в любом случае вызывается malloc() и в случае NULL вызывает либо библиотечный обработчик, либо пользовательский. malloc() нынче с субаллокатором внутри, поэтому надобность в new исчезла.
	Ответить | Правка | Наверх | Cообщить модератору

10. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+20 +/–
Сообщение от Аноним (-), 02-Мрт-24, 00:21
> 2.4 млн строк кода > 15 fuzzing-движков > 12 новых проблем, 8 были вызваны ошибками, приводящими к повреждению памяти Это просто офигенно. Одна ошибка памяти на 300к строк кода. Великолепный результат. Думаю другие проекты о таком и мечтать не могут. Вот оно превосходство современных плюсов (C++17) над Сишкой.
Ответить | Правка | Наверх | Cообщить модератору

	43. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	–1 +/–
	Сообщение от Аноним (43), 02-Мрт-24, 14:26
	Каждому известно, что если нужна безопасность, нужно обратиться к Майкрософт.
	Ответить | Правка | Наверх | Cообщить модератору

11. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+4 +/–
Сообщение от Bottle (?), 02-Мрт-24, 00:28
Удивительно мало уязвимостей. Вот что значит когда разработчики пишут на плюсах, а не чистых сях, обладают высокой квалификацией и используют статический анализ.
Ответить | Правка | Наверх | Cообщить модератору

	19. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+9 +/–
	Сообщение от Аноним (20), 02-Мрт-24, 01:31
	И оказывается никакой Rust для этого не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+1 +/–
	Сообщение от Аноним (30), 02-Мрт-24, 07:53
	Его пришлось продвигать: писатели на C не хотели переходить на C++. А теперь будут на Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 02-Мрт-24, 08:42
	Это Линус не хотел в одном проекте мешать идиомы RAII и goto error, но в угоду сообществу подвёл под это удивительную теоретическую базу. На чём теперь будут - это интересный вопрос. Удивительным образом Projected EOL всех последних LTS совпали с Dec, 2026. Что-то не припоминаю такого раньше.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (65), 02-Мрт-24, 21:14
	>Удивительным образом Projected EOL всех последних LTS совпали с Dec, 2026. Что-то не припоминаю такого раньше. Теория заговора :)
	Ответить | Правка | Наверх | Cообщить модератору

	36. Скрыто модератором	+1 +/–
	Сообщение от Аноним (36), 02-Мрт-24, 09:37
	Не будут. Перейдут на плюсы, го, котлин, сисярп, да хоть бидон, но не раст
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	42. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+2 +/–
	Сообщение от Карлос Сношайтилис (ok), 02-Мрт-24, 13:15
	Оказывается аналитики опеннета так и не поняли, что раст нужен не для написания безопасного кода, а для неписания небезопасного. Понимаю, что двойное отрицание, для некоторых, сложная ментальная конструкция, но призываю её хотя бы попытаться понять. Безопасно можно писать на любом ЯП, это вроде очевидно, но Раст бьёт разработчика по рукам и вставляет палки в колеса в опасных местах, в отличии от с/с++, где компиляторам вообще по барабану что там разраб творит.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	69. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+1 +/–
	Сообщение от Аноним (69), 03-Мрт-24, 05:37
	https://www.openwall.com/lists/oss-security/2021/05/18/1
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-24, 18:47
	Как это связано с тем что я написал? Или тебе нужен язык, который ещё и думать над логикой и архитектурой будет вместо тебя?
	Ответить | Правка | Наверх | Cообщить модератору

12. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	–6 +/–
Сообщение от kusb (?), 02-Мрт-24, 00:32
А кстати почему компиляторы не пишут на скриптовых языках? Они не критичны к производительности на самом деле. А когда отлаживаете - можно просто отключить оптимизацию и всё равно собирать быстро.
Ответить | Правка | Наверх | Cообщить модератору

	13. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	–1 +/–
	Сообщение от Аноним (9), 02-Мрт-24, 00:35
	потому что продвинутые компиляторы используют всякие векторные инструкции и прочие специфичные для целевого процессора штуки?
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+3 +/–
	Сообщение от Аноним (65), 02-Мрт-24, 01:55
	Они эти штуки сами не обязаны использовать в процессе своей работы, они эти штуки генерят на выхлопе своей деятельности. Поэтому, это действительно могут делать и компиляторы, сами написанные на скриптовых. Тут только вопрос скорости компиляции.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+5 +/–
	Сообщение от Bottle (?), 02-Мрт-24, 00:50
	Эммм, как раз наоборот. Если ты пытался собрать какой-нибудь крупный проект из исходников, то знаешь, это дело не на пять минут, а на полчаса и больше. Например, ядро Линукса является таким большим проектом. Или Либрофис. Или Хромиум.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	16. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+7 +/–
	Сообщение от Аноним (16), 02-Мрт-24, 00:52
	Ага щщщщас, некритичны, как же. Такое может говорить только человек, понятия не имеющий об устройстве современного оптимизирующего компилятора и не имевший дела с крупными проектами. Пойди, собери Webkit/Blink из исходников. Потом расскажешь о впечатлениях.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	17. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+1 +/–
	Сообщение от Аноним (9), 02-Мрт-24, 01:12
	Плюсовый компилятор на огромном проекте, когда разворачивает все шаблоны, неилюзорно так нагружает проц. И это компилятор написаный на C++. А так да, не критичны к производительности, ага.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	24. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	–3 +/–
	Сообщение от kusb (?), 02-Мрт-24, 02:50
	Ну да, но он запускается один раз. А при разработке можно не собирать с оптимизациями.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+2 +/–
	Сообщение от Аноним (-), 02-Мрт-24, 03:20
	> А кстати почему компиляторы не пишут на скриптовых языках? Потому что пересборка линукскернела растянувшаяся по времени на пару недель - это не очень круто, извини. Не критичны? Ох, серьезно?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	62. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+1 +/–
	Сообщение от kusb (?), 02-Мрт-24, 20:57
	То есть всё совсем сильно замедлится? Ну есть ещё языки с jit.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (-), 03-Мрт-24, 04:10
	> То есть всё совсем сильно замедлится? То-есть, скорость продвинутого оптимизера, особенно что-то типа LTO, ворочающего глобальный анализ немеряного куска кода - и жор оперативы этим - даже и в нативном коде бывает очень нетривиальным для больших проектов, и таки - напрягает. Сделать LTO на штуке с линукс керенл требует не комп - а компище. Ну вот реально EPYC топовый с десятками гигз оперативы минимум захочется. Зато ты только представь себе: четверть кода аннулируется нахрен - совершенно нахаляву, без урона производительности. А то и с бонусом к ней. > Ну есть ещё языки с jit. А, ну да, отличная идея во время компила оптимизить не только код который собираем - но и код компилятора. Вместо того чтобы его предкомпильнутым заранее сделать. Ну это то да, эффективно получится. По жору оперативы еще сильнее и нагрузке на проц ибо оптимизить теперь надо еще и код компилера заодно.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 02-Мрт-24, 08:22
	Потому что применительно к компиляторам исторически сложился такой критерий - True Thing. Когда компилятор языка Икс написан на языке Икс - это значит, что язык Икс достаточно крут даже для написания компилятора. Из чего следуют совсем другие вопросы про компиляторы скриптовых языков, и некоторых нескриптовых.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	35. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 09:24
	>про компиляторы скриптовых языков ого, есть такие ЯП "скриптовые"? это те в названиях которых есть слово "script"?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (41), 02-Мрт-24, 12:14
	Нет, ещё си, например. Это те, у которых можно указать экзешник в шебанге и он исполнит файл.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 15:16
	исполнит? интепретирует, то есть интерпретируемый ЯП.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 02-Мрт-24, 15:34
	"Ch is a C/C++ interpreter and scripting language environment"
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 15:41
	русский язык, есть еще литературный язык, стихотворный, жаргонный, мат-перемат. повторите свой комент на жаргонном языке.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 16:58
	> "Ch is a C/C++ interpreter and scripting language environment" почему не manuscripting language (manuscriptum, от лат. manus — «рука» и scribo — «пишу»).
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	61. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 02-Мрт-24, 20:46
	>> "Ch is a C/C++ interpreter and scripting language environment" > почему не manuscripting language (manuscriptum, от лат. manus — «рука» > и scribo — «пишу»). Это к авторам интерпретатора вопрос. В стандарте Си не помню требований к транслятору быть "компилятором".
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (41), 02-Мрт-24, 15:40
	Скрипты могут быть и компилируемыми, вот, к примеру, gdscript вполне скриптовый язык, которому нечего делать за границами среды (но и заменить его нельзя адекватно). Жава интерпретируется, но, в обычном виде -- это скомпилированный байткод для вм. А вот жаваскрипт в обычном виде интерпретируемая форма, которая преобразуется в скомпилированную и нативный код в процессе исполнения.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	49. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (41), 02-Мрт-24, 15:43
	Кстати, жаву ещё можно скомпилировать (GraalVM) и она будет исполняться без виртуально машины. А если заставить жаву просто исполнять файл, то это скриптовый язык. И в качестве скриптового языка, она даже использовалась в играх ещё лет 20 назад (как питон или луа).
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 16:54
	> то это скриптовый язык. я могу назвать его алгоритмическим языком? или процедурным языком? может функциональным? неее мульти-парадигменным языком может? ржавый язык - вот оно как. ЯП - язык программирования, и никаких СЯ - скриптовый язык. Русский язык, и никаких литературный, жаргонный, мат-перематный язык.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (41), 02-Мрт-24, 17:13
	Нет. Скрипты -- это то, что связывает части на нормальных яп и как правило тормозит и ничего не может по сравнению с ними (в теории и брейнфак полноценный яп). Обычно там ещё виртуальная машина, интерпретатор, зачастую сборщик мусора. Если смотреть с такой стороны, то жава и питон это одно и тоже, скриптятина. А вот го и раст скриптовые языки не в большей мере, чем си.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 17:25
	> Нет. Скрипты -- это то Скрипт, как и алгоритм, программа, функция, сценарий, инструкция - это "содержимое" (текст) на языке программирования. А "содержимое" на данном языке программирования либо компилируется, либо интерпретируется. Не скриптуется же ведь, чтобы он стал "скриптовым языком" программирования. И языки программирования делят именно по свойству компилируемости или интерпретируемости (язык сломался) :)
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (41), 02-Мрт-24, 17:40
	Я привёл пример с "полновесными" играми для ПК. Вся логика может быть либо на питоне, либо на луа, либо на жаве, в то время как всей отрисовкой и операциями с железом занимаются более производительные компоненты на низкоуровневых языках. Додиез несколько размывает эти границы, потому что на нём пытаются реализовывать не только "логику", но и "вычисления", и вообще всё, в следствие чего самые примитивные игры тормозят и жрут ресурсы как не в себя. Такое разделение на "полноценные яп" для всего и "игрушечные яп", в которых проще реализовать бизнес-логику, куда более логично. Вот игрушечные яп это обычно и есть скрипты. Взять тот же жс, который впихнули туда, где ему, очевидно, не место. Или перл, который как был языком обработки текста, так и остался. И даже если скомпилировать пхп, он не станет полноценным нескриптовым языком, ведь он занимается буквально тем, что совмещает сишные компоненты в себе.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 17:54
	> Я привёл пример с "полновесными" играми для ПК. В этом то и проблема, вы рассматриваете ЯП с точки зрения "содержимого" и классифицируете их по нему. > Такое разделение на "полноценные яп" для всего и "игрушечные яп", в которых > проще реализовать бизнес-логику, куда более логично. Это не допустимо в компьютерной науке, ибо не серьезно. > Вот игрушечные яп это обычно и есть скрипты. Взять тот же жс На том же JS можно линуксовый кернель написать, от этого он станет не игрушечным?
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 18:19
	> "игрушечные яп" приведу небольшую аналогию с процессорами, если текущий линукс кернель не запустится на каком-нибудь интел 8086 это же не дает ведь нам право говорить, что 8086 "игрушечный цпу". пс: https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	59. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (41), 02-Мрт-24, 18:57
	У брейнфака есть какие-либо перспективы стать неигрушечным через 10 лет, а сегодня он уже общепризнан и востребован мировым сообществом во всех областях применения? Может быть, его копируют тысячи компаний и организаций по всему миру?
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 21:02
	> по всему миру? ага, все во всем мире пользуются китайским языком, а остальные игрушки? А что это еще за "ржавый" язык придумали еще и пихают в линукс кернель? Детский сад развели ппц. Исходя из этой логики должен существовать один ЯП - асм, а все остальные по факту игрушки, с чем я могу быть полностью с вами согласен.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	68. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (-), 03-Мрт-24, 04:16
	> приведу небольшую аналогию с процессорами, если текущий линукс кернель не запустится на > каком-нибудь интел 8086 это же не дает ведь нам право говорить, > что 8086 "игрушечный цпу". Как угодно - но он свое в целом отлетал. Редкие исключения только подтверждают правиль: на данном этапе развития технологий уже мало кто юзает ЭТО именно - всерьез. Это вымирающая легаси технология, типа пятидюймового флопа. > пс: https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset Это также весьма немассовая и нишевая штука. А кто-то до сих пор на COBOL программит вообще. Но найти хоть 1 программу на COBOL в диком виде - это еще звезды должны так сложиться вообще. Да что там, некоторые даже паровые машины по приколу собирают. Но вот как основной источник энергии для производства... эээ....
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 03-Мрт-24, 11:06
	> Да что там, некоторые даже паровые машины по приколу собирают. Но > вот как основной источник энергии для производства... эээ.... вы считаете, что собрать паровый движитель - "раз плюнуть"? "игрушечное" такое изобретение? Я промолчу про то, что ресурсы (материальные и интеллектуальные) необходимы чтобы его собрать. Обычный механический арифмометр не способны собрать, утрата "первобытного" опыта большая проблема, за пиком прогресса неминуема деградация (до сих пор не поймут как они так "игрушечные" пирамиды в пустынях построили)
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	79. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (79), 07-Мрт-24, 14:38
	> до сих пор не поймут как они так "игрушечные" пирамиды в пустынях построили. Это миф. Мы достоверно не знаем КАК ИМЕННО часть этого было сделано, но мы знаем сразу несколько способов как это могло быть тогда сделано. То есть мы не знаем грубо говоря который из них. Знаем где и как брали гранит и песчаник, где карьеры (они там рядом в пределах прямой видимости, просто на "туристические" фото не попадают), как сверлили, чем сверлили, как таскали и т.д. Знаем практически вообщё все. И никакх "инопланетных технологий" там для этого не надо. И да, огромные многотонные блоки там буквально только у основания и нижних уровней - выше они мельчают. И да, мы знаем, что это делали не "рабы за миску маиса" (как ошибочно думали довольно долгое время), а рабочие на зарплате, причём работа считалась "престижной" и стабильной (относительно неплохо "кормили" даже в годы неурожаев). Короче, хватит плодить этот несчастный миф про "инопланетные технологии пирамид".
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	80. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 07-Мрт-24, 21:13
	> Короче, хватит плодить этот несчастный миф про "инопланетные технологии пирамид". я такого не утверждал.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	82. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (-), 15-Мрт-24, 17:18
	> вы считаете, что собрать паровый движитель - "раз плюнуть"? "игрушечное" такое изобретение? > Я промолчу про то, что ресурсы (материальные и интеллектуальные) необходимы чтобы его собрать. > Обычный механический арифмометр не способны собрать, утрата "первобытного" опыта большая проблема, за пиком прогресса неминуема деградация (до сих пор не поймут как они так "игрушечные" пирамиды в пустынях построили) Думаю осилят, и довольно просто. Тут надо не только знать "как сделать", но и "что сделать". Школота запросто в майнкрафте пилит многроровневые сумматоры. Т.е им нужно будет реализовать тоже самое, но в других ресурсах. Любой человек видевший счеты на картинке, сможет их реализовать сотней способов из разных материалов. А вот придумать их с нуля - это будет очень сложно. Конечно где-то все упрется в карго культ, или в миниатюризацию, или в то что именно эту лекцию по физике прогуливал... Но представь, что ты попаданец в египет и стал фараоном. (до каких аналогий я докатился /_-) У тебя есть ограниченные ресурсы (но на пирамиду хватит) и остаточные знания из школы и универа. С учетом того что медь уже добывается, думаю паровой двигатель у тебя уже заработал лет через 10. Т.к ты знаешь ЧТО нужно сделать. ps я уже молчу что Геронов шар был сделан в 1 веке нашей эры. Это примерно пополам от нас до пирамид. Просто в тот момент не увидели потенциала, тк труд рабов был дешевле.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	83. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 15-Мрт-24, 22:29
	> Думаю осилят, и довольно просто. ок > Тут надо не только знать "как сделать", но и "что сделать". > Т.к ты знаешь ЧТО нужно сделать. вот позиционную систему счисления придумали 2000 лет назад, говорите, что знаем, а теперь вопрос, почему "десятое число" (в десятичной позиционной системе счисления) мы обозначаем цифрами 10, а не 00?
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	84. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (84), 16-Мрт-24, 07:59
	>> Думаю осилят, и довольно просто. > ок >> Тут надо не только знать "как сделать", но и "что сделать". >> Т.к ты знаешь ЧТО нужно сделать. > вот позиционную систему счисления придумали 2000 лет назад, говорите, что знаем, а > теперь вопрос, почему "десятое число" (в десятичной позиционной системе счисления) мы > обозначаем цифрами 10, а не 00? тогда уж 010. А вообще, представь что у тебя тумблеры где везде 000000000 до бесконечности. Прибавляем старший "бит" слева, младший справа, по конвенции. И в путь. Оставим тут четыре "бита", для наглядности:   0000   ----   0001   0002   0003   ....   0009   0010   0011   0012   ....   0020   ....   9999
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	85. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 16-Мрт-24, 09:04
	> Прибавляем старший "бит" слева, младший справа, по конвенции. вот ключевой момент, прибавляем (добавляем) новый разряд, после исчерпания "старшего", а не заранее выстраиваем "нули" слева как незначащие. > И в путь. С Богом. 0 - 0 1 - 1 2 - 2 3 - 3 4 - 4 5 - 5 6 - 6 7 - 7 8 - 8 9 - 9 00 - 10 -> вуаля добавил новый разряд, а с какой цифры он должен начинаться? он же новый "из коробки", едем дальше... 01 - 11 02 - 12 03 - 13 .... 0000 - ? какое число? Так в чем же разница? А не больше чисел я отображу пользуясь 4-мя разрядами? Полная позиционная система счисления. Почему мы отказались от всей "мощности представления" знаками(цифрами) чисел позиционной системы счисления? пс: Даже Лейбниц не узрел полноты представления, когда писал про "двоичную систему", а в "Книге перемен" как раз изображена эта полнота, они об этом знали.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	86. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (-), 16-Мрт-24, 10:24
	> вот позиционную систему счисления придумали 2000 лет назад, говорите, что знаем, "возникла во второй половине третьего тысячелетия до н. э. в Древнем Египте (египетская система счисления)" Слегка побольше 2к лет) > теперь вопрос, почему "десятое число" (в десятичной позиционной системе счисления) мы > обозначаем цифрами 10, а не 00? Хм, а о какой из систем речь? Они развивались из одной идеи, но реализации были слегка разные "В старинных системах для записи одинакового числа использовались символы, рядом с которыми дополнительно помечали, в каком разряде они стоят. Потом перестали помечать разряды, но число всё равно можно прочитать, так как у каждого разряда есть своя позиция. А если позиция пустая, её нужно пометить нулём. В поздних вавилонских текстах такой знак стал появляться, но в конце числа его не ставили. Лишь в Индии нуль окончательно занял своё место, эта запись распространилась затем по всему миру. "
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	87. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 16-Мрт-24, 20:34
	> Слегка побольше 2к лет) эт к слову сказано было > Хм, а о какой из систем речь? написал вроде - в десятичной позиционной системе счисления > А если позиция пустая, её нужно пометить нулём. откуда такое правило? откуда появляется пустой разряд? не бывает пустого разряда. > В поздних вавилонских текстах такой знак стал появляться, но в конце > числа его не ставили. Лишь в Индии нуль окончательно занял своё > место, эта запись распространилась затем по всему миру. " 909 - разве 0 во втором разряде это ноль? 909 = 900 + 00 + 9?
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	51. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 15:50
	>Жава интерпретируется там два этапа, первый компиляция в байт-код, а дальше интерпретация байт-кода (не исполнение).
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	45. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 02-Мрт-24, 15:32
	"Скриптовые языки" было в сообщении, на которое я отвечал. Скорее всего, автор имел ввиду интерпретируемые. От чего смысл моего ответа особо не меняется - современные интерпретаторы обычно предварительно компилируют исходный текст в байт-код.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	50. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 15:45
	ну дык надо брать в таком случае в кавычки (как в данном коменте), ибо возникает вопрос
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 02-Мрт-24, 20:40
	Мне надо было, что бы спрашивающий меня понял, при этом не забивать ему голову лишним. Для чего написаны первые два предложения. Для любителей поспорить в третьем было буквально вот что: "Из чего следуют совсем другие вопросы про компиляторы скриптовых языков, и некоторых нескриптовых." и вопрос последовал.)
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 21:11
	> Для любителей поспорить а в чем спор то? вы хотите мне доказать существование "скриптовых" языков? Выше я пояснил почему не бывает таких языков. "Скрипт" от слова scribo — «пишу», то есть бывает "пишуший" и не "пишуший" языки?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от n00by (ok), 03-Мрт-24, 11:06
	>> Для любителей поспорить > а в чем спор то? вы хотите мне доказать существование "скриптовых" языков? Я хочу, что бы ты наконец уяснил. Когда ты задаёшь риторический вопрос, то мне очевидна попытка повернуть разговор в нужное тебе русло. Соответственно, именно тебе лучше знать, в чём твой спор и что ты хотел себе доказать. > Выше я пояснил почему не бывает таких языков. "Скрипт" от слова > scribo — «пишу», то есть бывает "пишуший" и не "пишуший" языки? Вот потому скриптом на жаргоне называют файлик, который быстро накатали (или подправили) и запустили на исполнение. Обычно это интерпретируемый язык. И даже если бы скриптом называли пьесу Шекспира, это бы не изменило суть моего ответа - он про True Thing, а не про забивание головы спрашивающего ненужной ему терминологией.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Sw00p aka Jerom (?), 03-Мрт-24, 12:50
	> И даже если бы скриптом называли пьесу Шекспира Вот именно назвали пьесу (текст, содержимое), а не язык (англ) на котором написан этот "скрипт". Мне продолжать пояснять или на этом остановимся?
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Анонус (?), 02-Мрт-24, 10:03
	PyPy
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	38. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от penetrator (?), 02-Мрт-24, 10:26
	ага точно, ты когда-нибудь билдил что-то большее чем хелоуворд? сишные проекты вообще медленно билдятся но даже какой-нибудь моно когда собирает ассембли не блещет скоростью
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	39. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от Аноним (39), 02-Мрт-24, 10:41
	> Они не критичны к производительности на самом деле. Для хоум юзера — некритичны. А вот на работе, где сборочные фермы для CI стоят от нескольких сотен тысяч баксов — очень даже критичны.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

22. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	–2 +/–
Сообщение от Аноним (20), 02-Мрт-24, 02:04
Куда больший интерес сейчас представляет AI-Powered Fuzzing. Натравил модель на свой код, вуаля - все безопастно аж дальше некуда при почти нулевых усилиях. Вот оно, будущее безопастности.
Ответить | Правка | Наверх | Cообщить модератору

	25. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+7 +/–
	Сообщение от Аноним (25), 02-Мрт-24, 03:14
	Опять "волшебные" таблетки под новой упаковкой продают. ИИ не магия, работать за вас не будет, по эффективности проигрывает классическим алгоритмам, а фьюзинг итак время и ресурсоъемкий.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+1 +/–
	Сообщение от Аноним (-), 02-Мрт-24, 03:19
	> Куда больший интерес сейчас представляет AI-Powered Fuzzing. Натравил модель на свой код, > вуаля - все безопастно аж дальше некуда при почти нулевых усилиях. > Вот оно, будущее безопастности. Вон там в соседней новости - будущее безопасности. Когда ты скачал модель, запустил, она тебя раз@#$ла нафиг - и байбай.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	29. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+1 +/–
	Сообщение от Alladin2 (?), 02-Мрт-24, 05:16
	Доверять ИИ безопасность кода? Это тому самому ИИ который часто любит выдумывать и глючить..
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	40. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+2 +/–
	Сообщение от Аноним (-), 02-Мрт-24, 11:16
	Идея на самом деле неплохая. Просто скармливаете нейронке все CVE, найденные в ядре, за последние 10-20 лет и пусть ищет "похожие конструкции". А там уже человек глазенками просмативает.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	74. "Опубликованы результаты аудита безопасности кодовой базы LLV..."	+/–
	Сообщение от bOOster (ok), 05-Мрт-24, 14:15
	И лжеИИ в определенном моменте зацикливается.
	Ответить | Правка | Наверх | Cообщить модератору

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

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