The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%, opennews (?), 03-Янв-22, (0) [смотреть все]

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


18. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от Аноним (18), 03-Янв-22, 11:51 
Ява же любит кушать память
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

37. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –7 +/
Сообщение от iZENemail (ok), 03-Янв-22, 12:16 
> Ява же любит кушать память

Пальму первенства по этому свойству она давно отдала Rust'у.


Ответить | Правка | Наверх | Cообщить модератору

86. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +5 +/
Сообщение от Rev (?), 03-Янв-22, 13:48 
А будут ссылки на доказательства, или ты просто балабол?
Ответить | Правка | Наверх | Cообщить модератору

96. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –1 +/
Сообщение от Аноним (96), 03-Янв-22, 14:16 
Из книжки Rust:
Гарантии безопасности памяти в Rust затрудняют, но не делают невозможным случайное выделения памяти, которая никогда не очищается (что известно как утечка памяти ). Полное предотвращение утечек памяти не гарантируется Rust, так же как не является гарантией отсутствие гонок данных проверенных во время компиляции, а это означает, что утечки памяти безопасны в Rust.

В реальности:
Так же как Java безопастный раст может схавать столько памяти, сколько ей дадут или пока не прибьют OOM киллеры, т.к. память течет.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

253. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +1 +/
Сообщение от Аноним (253), 04-Янв-22, 15:30 
Затем что невозможно избежать утечек памяти. Это как пытаться избежать языковыми средствами возможности зацикливания (проблема останова). Можно, но не будет уже полноты по Тьюрингу.

Ошибка здесь такая. Вы утверждаете что ремень безопасности не уберегает от летальных случаев на дорогах и потому не нужен.

Ответить | Правка | Наверх | Cообщить модератору

286. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от Аноним (286), 04-Янв-22, 18:06 
>Затем что невозможно избежать утечек памяти.

Тогда и не надо было пыжиться, пытаясь заменить C++, Rust отличная замена сишарпа, только вот с такими приколами в нишу сишки с плюсами ему не пролезть.

Ответить | Правка | Наверх | Cообщить модератору

307. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от Аноним (253), 04-Янв-22, 21:45 
Сишарп на виртуальной машине работает. Его сравнивать с Rust/C++/C некорректно, можно с Явой.

Раст (по примеру ремня безопасности в машине) избавит от 70% эксплуатируемых уязвимостей. Напомню, что утечка памяти в программе на rust это максимум denial-of-service класс атаки.

https://www.zdnet.com/article/chrome-70-of-all-security-bugs.../
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro.../

Ответить | Правка | Наверх | Cообщить модератору

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

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

283. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от Аноним (286), 04-Янв-22, 18:00 
>разработчики Rust предупреждают, что

сборка мусора не работает и надо использовать костыли, а криков-то по поводу free() было...

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

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

431. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от Аноним (431), 12-Янв-22, 07:20 
>разработчики Rust предупреждают, что говнокод может течь

На Rust бывает другой код?

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

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

У тебя нет, независимо от ЯП.
Но не все люди - ты.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

170. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от лютый жабби__ (?), 03-Янв-22, 21:03 
>В джаве так-то можно JVM указать, сколько хипа она максимально может выжрать

и как это опровергает фразу "жаба жрёт ОЗУ как свинья помои"? Погугли сколько памяти в жабе занимает Double или Integer )

И, кстати, делать 100500 одноразовых иммутабельных объектов (и массово заниматься их копированием с места на место) - это прямая рекомендация от корифеев многопоточного погромирования на жабе )

Ответить | Правка | Наверх | Cообщить модератору

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру