|
|
|
|
|
6.120, Ноним (?), 00:51, 13/07/2020 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| –3 +/– |
Дано: AMD Athlon(tm) II X2 220 Processor, 4Gb RAM
Ubuntu 12.04: все летает, не более 1Гб рамы занято, свопа не нужно
Ubuntu 14.04: работает, без свопа не ок, можно жить, но ядро нужно ставить 4.4 из xenial
Ubuntu 18.04: тормозит, своп постоянно забит, переключение окон тормозит, все тормозит, и похоже что ядро течет
Последнее нормальное ядро - это 2.6.32, ветка ядер 3.x - адовое тормозилово, ядра 4.x получше, но еще не тестировал
Вообще, весьма интересно будет попробовать нарисовать какие-то тесты чтобы можно было бы говорить предметно, с цифрами
| |
|
7.216, Аноним (-), 18:35, 15/07/2020 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> Ubuntu 18.04: тормозит, своп постоянно забит, переключение окон тормозит, все тормозит,
> и похоже что ядро течет
Переходи на debian 10 с xfce, ядро по вкусу, это пофиг :D
> Последнее нормальное ядро - это 2.6.32, ветка ядер 3.x - адовое тормозилово,
> ядра 4.x получше, но еще не тестировал
В убунте проблема ну вообще совсем не в ядрах. Ядро это наименее проблемная часть убунт, но они успешно справляются с торможением, напихивая в систему всякое гомно на пихоне и тому подобное счастье :)
| |
|
|
|
|
|
|
|
|
|
|
7.127, Аноним (94), 04:57, 13/07/2020 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
Я понятия не имею и не хочу гадать. Я не разработчик ядра. Не был разработчиком ядра на C и не планирую присоединяться на rust. Более того, я не занимаюсь гаданием о том, чем там "корпорации" занимаются и не очень люблю копаться в заговорческих теориях о том как майкрософт (судя по всему, руками людей из других компаний) собирается уничтожить Linux (или к чему это "EEE (TM) мелкософт" было?). Мой комментарий не отвечал на критику использования rust в ядре, он отвечал на заявление вида "если ты попробовал rust, то ты фанбой и твой кругозор сузился". Нет, это не то, как это работает. А обсуждение зачем в ядре rust, какую проблему он решит, какие проблемы он принесет и т.п. я оставлю разработчикам ядра, потому что рассуждать на уровне выше "бабок на базаре" мои знания мне не позволяют.
| |
|
|
|
|
|
|
|
|
|
4.47, Аноним (47), 12:58, 12/07/2020 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +3 +/– |
Если бы был компилятор/препроцессор C каждый раз, когда делается что-то потенциально опасное требовал бы писать какую-нибудь директиву типа #unsafe, думаю само это уже чуток, но улучшило бы качество продукта.
Другой вопрос что в классическом C это пришлось бы писать почти везде и сильно ухудшило бы качество уже кода.
Как быть когда народ, бизнес, нарастающая сложность требует гарантий, хоть каких-то?
Rust как раз отражает возникший спрос. Соответствует ли он ему, это уже другой вопрос.
Но уже понятно, что просто сказать "лучше тестируйте", "нанимайте профи" и т.п. уже не достаточно.
Что-то он это улучшит, где-то поднимет дискуссию, где-то сам Rust потом еще будут допиливать...
| |
4.49, Аноним (189), 13:11, 12/07/2020 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +7 +/– |
Увы, мнение об отключении всех проверок в unsafe — это типичное заблуждение, потому что в документации к языку Rust сказано, что unsafe позволяет:
Разыменовывать сырой указатель;
Вызывать и объявлять unsafe функции;
Читать или измененять статическую изменяемую переменную;
Реализовывать и объявлять unsafe типаж;
Получать доступ к полям union.
Ни о каких отключениях всех проверок Rust здесь и речи не идет. Если у вас ошибка с lifetime-ами, то просто добавление unsafe не поможет коду скомпилироваться. Внутри этого блока компилятор продолжает проверять код на соответствие системы типов, отслеживать время жизни переменных, корректность на потокобезопасность и многое-многое другое. Подробнее можно прочитать в статье You can’t "turn off the borrow checker" in Rust.
К unsafe не стоит относиться как "я делаю, что хочу". Это указание компилятору, что вы берете на себя ответственность за вполне конкретный набор инвариантов, которые компилятор самостоятельно проверить не может. Например, разыменование сырого указателя. Это мы с вами знаем, что сишный malloc возвращает NULL или указатель на аллоцированный кусок неинициализированной памяти, а компилятор Rust об этой семантике ничего не знает. Поэтому для работы с сырым указателем, который вернул, к примеру, malloc, вы должны сказать компилятору: "я знаю, что делаю; я проверил, там не нулл, память правильно выравнена для этого типа данных". Вы берете на себя ответственность за этот указатель в блоке unsafe.
| |
|
5.62, Аноним (62), 13:49, 12/07/2020 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| –2 +/– |
>к примеру, malloc, вы должны сказать компилятору: "я знаю, что делаю; я проверил, там не нулл, память правильно выравнена для этого типа данных". Вы берете на себя ответственность за этот указатель в блоке unsafe.
Ровно тоже делает разработчик на С, далее приводит указатель к нужному типу, работает с ним и освобождает. В С++ operator new ещё и возвращает указатель нужного типа на полностью сконструированный объект и может бросить (он или конструктор объекта) исключение, а деструктор освободит все ресурсы выделенные объектом. Или раст в состоянии автоматически освободить системный хэндл или указатель выделенный в ансейф блоке?
| |
|
|
|
|
|
|
|
4.79, nelson (??), 15:51, 12/07/2020 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +1 +/– |
> Но Rust то рвёт всех как Тузик грелку
Особенно по скорости компиляции, ага.
> Представляете себе лицо Линуса, когда ему дают вариант в 2.71 — 3.15 раз более оптимальный, чем он написал на Си?
В каком плане более оптимальный? Как раз таки Си - наиболее оптимальный ЯП для решения задач из области разработки системного ПО и, тем более, ядер ОС из существующих в природе. В идеале, конечно, ядро ОС должно реализовываться на более низкоуровневом ЯП'е, нежели С, но, за неимением такового, приходится использовать последний. Высокоуровневые ЯП'ы с функцией подтирания соплей за нерадивыми разрабами в этой области нафиг не сдались.
| |
|
5.134, n00by (ok), 07:08, 13/07/2020 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
>> Но Rust то рвёт всех как Тузик грелку
> Особенно по скорости компиляции, ага.
>> Представляете себе лицо Линуса, когда ему дают вариант в 2.71 — 3.15 раз более оптимальный, чем он написал на Си?
> В каком плане более оптимальный? Как раз таки Си - наиболее оптимальный
> ЯП для решения задач из области разработки системного ПО и, тем
> более, ядер ОС из существующих в природе.
Это не совсем так. Си всем понятен, это не всегда хорошо. Вы пробовали отправлять код в ядро? Сразу же отвечают: вот тут ошибка, вот так не пишут, и так далее. Приходится читать очередную главу из Кернигана и Риччи. Очень долго и не оптимально.
| |
|
|
|
|
5.251, Совершенно другой аноним (?), 14:55, 07/08/2020 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
Не совсем понятно почему? Там-же большая часть контролей, вроде, на уровне компилятора. Т.е. сам компилятор контролирует, что что-то куда-то не вылезло и ни на кого не налезло.. Runtime-проверок должно быть не больше, чем в C, иначе не понятно, почему Rust на уровне, а по заявлению некоторых, и быстрее, чем C.
| |
|
|
|
|
|
|
3.99, Ретроград (?), 17:59, 12/07/2020 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| –1 +/– |
А ты, похоже, даже в своем расте не разбираешься.
Core - это и есть внешняя зависимость. Более того, в этом Core куча примитивов, которые в ядре просто неприемлемы, но которые требуются всякими языковыми конструкциями. Собственно, это основная претензия к расту - он абсолютно неюзабелен как системный ЯП из-за этого. Если бы это просто был "Си со сборкой мусора во время компиляции", ядро бы давно уже на него перешло.
| |
3.107, nelson (??), 20:22, 12/07/2020 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> у раста есть ядро, которое работает вообще без внешних зависимостей
It is the portable glue between the language and its libraries, defining the intrinsic and primitive building blocks of all Rust code.
и что с того, если это ядро не входит в реализацию самого ЯП и при этом реализует его возможности, т.е. является, по сути, внешней зависимостью? ЯП, требующий зависимости для использования языковых конструкций? ЯП, не обладающий zero runtime для реализации ядра ОС - ну чё, круто. стильно, модно, смузихлёбно
| |
|
|
|
2.234, Аноним (234), 20:27, 15/07/2020 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> Линуса задолбали. Он возьмёт тактику, что будет соглашаться с тем, что ржавый
> в ядре нужен, но разносить все попытки его туда засунуть. Молодец,
> так и надо. Это уже политика
Торвальдс вообще сообразительный тип - вы там пободайтесь с этим, на публику, и в моем формате, а я посмотрю выйдет ли у вас чего дельное и не задолбаетесь ли :)
| |
|
|
|
3.129, Anonn (?), 05:41, 13/07/2020 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
Тем не менее мы регулярно имеем баги/уязвимости с использыванием разыменования указателя, nil-указателя, переполнения буферов, стеков и прочих типичных си-ошибок, даже переписывание констант, практически во всех подсистемах линукса. Здесь уже на кривые руки автора не спишешь - если язык это позволяет, то где-то оно рано или поздно, намеренно или случайно всплывет.
| |
|
|
|