В ядре Linux выявлено три уязвимости, которые потенциально позволяют локальному пользователю поднять свои привилегии в системе:...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54542
Вот и пришло время Rust 4 Kernel.
Перепишешь?
охотно, но не уверен, что Линусу это понравится
Вначале может и нет, а потом распробует.
Как у него с корпорациями произошло.
- Владимир Иванович, а как вы оцениваете ситуацию с "приглашением на работу" в США двух российских хакеров, после чего они были арестованы ФБР?- Это достаточно взрослые люди, которые должны были понимать меру своей ответственности, выезжая за границу в надежде поправить свое материальное положение. Такое решение принято, по всей видимости, добровольно. Ситуация примет другой вид, если эти люди не виновны. Во всяком случае, зарубежные правоохранительные органы должны были обратиться к российским коллегам за оказанием правовой помощи в установленном порядке.
> Вначале может и нет, а потом распробует.
> Как у него с корпорациями произошло.ну то есть никак
Ну как же никак?
Покаялся. Инклюзивную лексику принял. СистемД принял. Уверен и Редхат с МС давно плюбил.
У Linux давно есть технология позволяющая исключить возможность эксплуатации проблемы вызванной обращением к уже освобождённой области памяти (use-after-free): https://www.opennet.me/openforum/vsluhforumID10/5560.htmlПочему Линус Торвальдс ее не принял в ядро?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...Планы:
"Counter integrity
-----------------Many places in the kernel use atomic counters to track object references or perform similar lifetime management. When these counters can be made to wrap (over or under) this traditionally exposes a use-after-free flaw. By trapping atomic wrapping, this class of bug vanishes."
Сделано:
Memory poisoning
----------------When releasing memory, it is best to poison the contents, to avoid reuse attacks that rely on the old contents of memory. E.g., clear stack on a syscall return (``CONFIG_GCC_PLUGIN_STACKLEAK``), wipe heap memory on a free. This frustrates many uninitialized variable attacks, stack content exposures, heap content exposures, and use-after-free attacks."
Чистка памяти при освобождении чуть замедляет работу ПО и в Ынтерпрайз дистрах использоваться не будет, как и многие другие опции безопасности. Почему? Потому что Ынтерпрайз пользователь на вопрос "вам быстро и дешево, или хорошо и безопасно", отвечает - "быстро и дёшево"!
Ну так форкни и покажи ему мастеркласс. Он даже гит напрогал для этого. Wait, oh shi- (там ведь тоже сишка)
Pijul тебя подери!
> Pijul тебя подери!Не надо питбуля! Мне кота хватило, с запасом.
Я с ним договорился. Он согласен. Ждем код завтра.
> Вот и пришло время Rust 4 Kernel.Специалисты утверждают что для большей безопасности надо пеперисать как минимум два раза.
Второй раз на Haskell.
> Второй раз на Haskell.При том сначала самого автора. Иначе он спятит до того как это освоит.
Хаскель растаману? Вы хотите, чтобы у него взорвался мозг?
Ммм... вакуумная бомба? :)
давайте, а мы запасемся попкорном и кока-колой и поржем, там ггде-то рукожооп из мелкософта плачет и ждет ваше генитальное поделие.
3.14даRUSTы всех стран объединяйтесь!
Я уже устал комментировать этот сишный дуршлаг
В отличие от несуществующего ядра на хрусте этот дуршлаг внезапно работает
Хватит даже того, что оно просто есть.
Овотар вирни!
>несуществующего ядра на хрустеА как же redox? Это даже целая ОС, а не просто ядро.
Оно ещё и работает?
Я не про идеальные сферические в вакууме условия, а реальные боевые инсталляции :)
Так, не виляй. Речь шла про отсутствие ядра, я опроверг. Да, в виртуалочках работать должно. На железе не знаю.
Реактос "на виртуалочках" уже лет 20 "работает". Только кому такая "работа" нужна? Это даже потребности разработчиков не покрывает, так что они пищат, кряхтят, но юзают в результате ... явно не свою операционку. Что довольно плохо для развития системы и реалистичного взгляда на мир.А, ну да, при кодинге этой шляпы вы совершенно случано заметите что posix'ное апи максимально дурацкое, с весьма unsafe структурой и сделать это безопасТно врядли получится, а если попытаться сделать next-gen - под него софта будет ноль целых, фиг десятых. И получится - нет, даже, блин, не гайка...
На реальном железе запускается https://www.redox-os.org/news/focusing-on-rustc/.
Не на всем разумеется, но то что запускается это факт.
> На реальном железе запускается https://www.redox-os.org/news/focusing-on-rustc/.Да так то и жедитоба с ракатосом нашел какой-то хлам на котором оно запускается. Проблема в том что повседневной осью оно так и не стало, даже для своих разработчиков.
И как показал пример - когда девы не находят в себе силы поюзать свое нечто хотя-бы для себя, остальным оно оказывается и тем более нафиг не надо. Поляна не вытоптанная оказывается, пользоваться малореально. А девовская система - далеко не самый требовательный кейс для операционки, там по большому счету достаточно работы джентльменского минимума в не сильно похабном виде. Если проблемы даже с этим, остальные совсем без шансов.
О! Переобувания в воздухе продолжаются.
Было утверждение что нет ядра - вам показали ядро.
Потом сказали что оно не работает - вам показали что оно даже на железе запускается.
А теперь само железо оказывается хлам!
Ноут с процом 8 поколения (а это 2017 год на минуточку). Ну-ну))До повседневной оси ему еще топать и топать. Ею даже линукс не стал (сколько там процентов на десктопе?).
> Ноут с процом 8 поколения (а это 2017 год на минуточку). Ну-ну))Ну так где хотя-бы разработчики юзающие свое добро? А, в фаундейшне пилят гранты и набивают цену чтобы продаться подороже?
> До повседневной оси ему еще топать и топать. Ею даже линукс не
> стал (сколько там процентов на десктопе?).Да какая мне разница сколько там процентов, если он мои задачи ворочает? А вон то до этого состояния судя по всему и за 20 лет не дойдет. Так, глядя на реактос и прочие микроядра. Но вы в вашем праве продемонстрировать на примере своих тушек чего все ваши яп и концепции стоят - начав юзать свой шит хотя-бы для самих себя. Иначе неубедительно. Особенно когда у вас даже, цуко, кодогенератора на вашем хрусте нет, чота здоровенную плюсатую либу приперли.
Т.е. для начала хруст даже не бутстрапнулся как таковой. Нельзя собрать хруст только хрустом, это даже код генерить не сможет. Зато про системность - расчирикались.
Вы видимо совсем не понимаете суть диалога, как я погляжу. Речь шла _только_ про отсутствие ядра. Не про работоспособность, заметьте. Но ядро даже работает. Про актуальность и нужность речи тоже не шло. Мне эти ни к чему знать.
Окей. Исправляюсь.В отличие от условно запускающегося ядра на хрусте этот дуршлаг внезапно работает, и работает хорошо.
Удивительное рядом -- написанная на языке пятидесятилетней давности тридцателетняя программа сложнее программ на языке, который стабилизировали пять лет назад. Срочно в новости, лол.
Есть очень простая вещь: пользоваться будут тем, что работает.
Поэтому хотите вы или не хотите, а "ой, нам всего пять лет, и мы умеем только запускаться" - шансов не имеет.
И к слову, ядро Linux даже в первые пять лет развивалось куда серьёзнее. В 1994 уже были вполне серьёзные заявки в виде Debian GNU/Linux, Red Hat и SUSE - коммерческие - если что, хотя версия 0.01 ядра только в 1991 появилась.
А в 1995 - педивикия подсказывает - оно уже работало на x86, DEC и SPARC, а не просто запускалось.
Да, я понимаю, что за сам язык говоришь, а не за редокс, и напираешь на то, что "какие могут быть ожидания за 5 лет всего языку". Именно так - никаких ожиданий, о чём я как раз и пытаюсь сказать. Оно ещё взлететь-то не готово, а мы уже на нём пытаемся ОС писать.
А ты тоже не виляй. У меня есть вообще идеальное ядро. На совершенно новом мной придуманном языке совершенно безопастном и с идеальным синтаксисом.Оно тоже не работает, его никто не видел, но оно есть. Так счиается.
Утчки в хрусте своём почините.
Тебе так лень открыть сайт redox? Ваша аналогия совершенно некорректная.
С кем вы сражаться собрались этими инсталляциями?
>Оно ещё и работает?В процессе загрузки выдаёт "Hello World!", потом уходит в глубокий защищённый режим. Её оттуда не достать.
> А как же redox?На расте невозможно написать даже вызов ядра... Раст живёт только выше libc. Всё что ниже - на Си. Ваша ресдох оказалась всего лишь обёрткой си-методов.
Ты бы хоть разобрался в теме для начала. Советую зайти на главную страницу Redox и прочесть:
>Custom libc written in Rust (relibc)
Да-да, на расте... обёртка вокруг си на расте. У раста нет возможности вызывать ядро.
мсье совсем слаб. там вообще все ядро на расте...
Да-да, на расте... На асме с ржавой обёрткой. Потом снова асм (на расте же написать что-то полезное невозможно), потом опять обёртка... И так много-много слоёв ржавой матрёшки.
"Rust пригоден для системного программирования, в частности, он рассматривается как перспективный язык для разработки ядер операционных систем" @Википедия
"Redox > Языки программирования: Rust, Язык ассемблера" @Google
И хватит тут оффтопию разводить.
Педовикия, гугл - очень надёжные источники.
Твои комментарии точно менее надежные, так что давай-ка реальный пруф на свое утверждение
Какой тебе пруф? Что на расте невозможно написать вызов ядра? Ну опровергни - приведи пример... Только без асма.
>> На расте невозможно написать даже вызов ядра... Раст живёт только выше libc. Всё что ниже - на Си. Ваша ресдох оказалась всего лишь обёрткой си-методов.Для начала, пруф на то, что в редоксе ниже libc сишный код. Но ты этот пруф конечно не приведешь, потому что тебе уже показали, что даже ядро там на расте.
> Ну опровергни - приведи пример... Только без асма.
Не приведу, и если соглашаться с твоей позицией, то тогда необходимо признать, что не существует системных языков высокого уровня, и даже си не является системным. Ну либо приведи пример, и расскажи, почему в каких нибудь glibc, musl, bsd libc без него невозможно обойтись
> Не приведуВот видишь, на расте невозможно что-то написать. Выше растаманы уже показали свою несостоятельность.
Нельзя сделать вызов ядра без асма, значит ничего нельзя написать, я тебя правильно понял? Что там с ответами на остальные вопросы?
>> А как же redox?
> На расте невозможно написать даже вызов ядра... Раст живёт только выше libc.*очередной анонимный выброс метана?*
https://docs.rs/syscall/0.2.1/syscall/platform/fn.syscall0.html
//! This library was built for x86-64 Linux.pub mod nr;
#[inline(always)]
pub unsafe fn syscall0(n: usize) -> usize {
let ret : usize;
asm!("syscall" : "={rax}"(ret)
: "{rax}"(n)
: "rcx", "r11", "memory"
: "volatile");
ret
}
> Всё что ниже - на Си. Ваша ресдох оказалась всего лишь обёрткой си-методов.*аноним продолжает насыщать метаном водоемы?*
https://github.com/redox-os/syscall
> Rust 99.3% Shell 0.7%
pub unsafe fn syscall0(mut a: usize) -> Result<usize> {
llvm_asm!("swi $$0"
: "={r0}"(a)
: "{r7}"(a)
: "memory"
: "volatile");Error::demux(a)
}
> asm!("syscall" : "={rax}"(ret)
>
> : "{rax}"(n)
>
> : "rcx", "r11", "memory"
>
> : "volatile");
> retОчень странный раст. Может он еще и safe? :)
>> asm!("syscall" : "={rax}"(ret)
>>
>> : "{rax}"(n)
>>
>> : "rcx", "r11", "memory"
>>
>> : "volatile");
>> ret
> Очень странный раст. Может он еще и safe? :)Очень странный спрыг с темы оберток и "невозможно написать даже вызов ядра".
man 2 syscall
Architecture calling conventions
Every architecture has its own way of invoking and passing
arguments to the kernel. The details for various architectures
are listed in the two tables below.Arch/ABI Instruction System Ret Ret Error Notes
call # val val2
───────────────────────────────────────────────────────────────
x86-64 syscall rax rax rdx - 5
Может, для питоножсников и выглядит очень странно использовать оф. ABI вместо /dev/astral, кто же их знает.
asm код, это не rust код.
О-о-о, дружочек. С таким пуристским подходом ты далеко зайдешь.Так-то может оказаться что на кристально чистом С вообще ничего не написано.
Или мы не понимаем, и это другое ?
> Или мы не понимаемА разве растаманы вообще хоть что-то понимают? Они пишут на асме, а говорят, что это раст...
> Они пишут на асме, а говорят, что это...Так и запишем, насильники-имбецилы пишут на асме, и говорят что это С
Забавно всегда читать диалоги о расте. Они все сводятся к одному алгоритму:
- раст safe
- но так ведь вот это ХХХ не можете
- можем, unsafe
- ну так теперь не безопасно
- у нас все безопасно и мы все можем, а ты иди н****
> Очень странный спрыг с темы оберток и "невозможно написать даже вызов ядра".Так это, где в данном фрагменте проявляются хваленые преимущества хруста? Утверждается что это safe? Или нахрена козе баян? На асме я могу и без хруста попрогать. И даже без сей. Правда и корректность этого кода как-то исключительно на мне будет, так что растовики идут с своими сказками лесом.
Что и требовалось показать, на расте только обёртки вокруг небезопасного (!) асма. Вопрос: какую проблему решили растаманы, заменив пару слов "asm" и "syscall" из нормальных языков на несколько экранов ржавого бреда?!Неудивительно, что за 15 лет растаманы в Мозиле смогли написать не более 10% кода, после чего их уволили как "неоправдавшие доверие". Причём эти 10% кода - эквивалент 1% исходного, который они переписывали.
> какую проблему решили растаманы, заменив пару слов "asm" и "syscall" из нормальных языков на несколько экранов ржавого бреда?!А они меняли?
> Неудивительно, что за 15 лет растаманы в Мозиле смогли написать не более 10% кода
Они не тупорезы, переписывать ради того, чтобы переписать. Это тут, на опеннете, чтобы доказать местным икспертам состоятельность языка, надо весь мир мгновенно переписывать
> после чего их уволили как "неоправдавшие доверие"
Пруф
> Причём эти 10% кода - эквивалент 1% исходного, который они переписывали.
Пруф
> Что и требовалось показать, на расте только обёртки вокруг небезопасного (!) асма.Ты хотел вообще-то показать "На расте невозможно написать даже вызов ядра ... Всё что ниже - на Си. Ваша ресдох оказалась всего лишь обёрткой си-методов."
С последней частью - обделался, с первой частью: с нетерпением ждем демонстрацию вызова ядра вида "как делается в правильных языках".> Вопрос: какую проблему решили растаманы, заменив пару слов "asm" и "syscall"
> из нормальных языков на несколько экранов ржавого бреда?!Решили проблему вызова ядра согласно спекам этого самого ядра, очевидно же.
Кстати, расскажи поподробнее о "нормальных языках" со словом "syscall" и еще немного об "экранах ржавого бреда" - но чур, только после демонстрации "как надо правильно на чистейшем Си".
> Неудивительно, что за 15 лет растаманы в Мозиле смогли написать не болееhttps://mail.mozilla.org/pipermail/rust-dev/2012-January/001...
> Fri Jan 20 14:34:26 PST 2012
> The Rust compiler 0.1 is unleashedКто-то анонимный опять обде^W обогатил метаном лужу?
Самое интересное, что с firecracker примерно такая же история происходит в Фармазоне: растаман никак не могут запустить его в production
Будь мужыком, перейди на Redox. Иначе коментировать придется еще лет 50, а там или шах, или ишак.
> Будь мужыком, перейди на RedoxЭто как послать. Хотя для растаманов это норма туда ходить.
А почему бы их и не послать? Они так прикольно быкуют на си и плюсы, но без них им не только будет не на чем компилер запускать - но они даже и код генерить не смогут, ведь LLVM не на расте.Так что на расте можно написать компилер который не компилит и браузер который не браузит. Зато понтов развели хуже питонистов. Впрочем, судя по развитию истории с hg - именно на них и расчитано.
> А почему бы их и не послать? Они так прикольно быкуют на си и плюсы, но без них им не только будет не на чем компилер запускать - но они даже и код генерить не смогут, ведь LLVM не на расте.Эксперды опеннета в своей естесвенной среде обитания ...
https://rustc-dev-guide.rust-lang.org/backend/codegen.html
> rustc uses LLVM for code generation; there is also support for Cranelifthttps://github.com/bjorn3/rustc_codegen_cranelift
> features = ["std", "read_core", "write", "coff", "elf", "macho", "pe"]
> Rust 95.8% Shell 4.2%
> Я уже устал комментировать этот сишный дуршлагБудто ты не получаешь от этого странное, непонятное заурядному Анониму удовольствие.
Ты думаешь, что заурядному Анониму оно непонятно? Я лучше о нём думал.
Кроме шуток, какие языки программирования считаешь без дыр?
бейсик :)))))))))))))
peek, poke есть значит и дыры будут...
Ada
Ocaml.
И слава богу.
> Я уже устал комментировать этот сишный дуршлагБратуха, та достал, та хоть бутылки из комнаты своей убери, воняет жешь недопитое и разлитое. Про сходить в душ я уже молчу. А то уже даже iPony домой пригласить страшно.
Позорище.
Чтозанах? Демоны взбунтовались? Говорт, фрактал ненастоящий?!
Похоже ему переполнили изветсно что
А чего ты хотел? Такому недоумку крышу снести рас плюнут.
Где бан? Почему тебя не банят? Ты флудишь во всех темах и нарушаешь правила форума, но тебя не банят, почему?
Какого форума, поехавший? Это комменты к новостям.
Тебе банов захотелось ? Для начала создай себе почту, погладь рубашку, зарегистрируйся, зайди с домашнего ойпи и потом трынди тут про баны.
Не ужели устал? Рука заболела, попробуй другой, вдруг получиться.Девушку найти не предлагаю, не даст тебе никто.
В каком смысле устал? Я думал, ты бот
В UNIX гарантия безопасности идёт от среды исполнения - ядра OS и процессора, а не от компилятора. Хоть компилятор для безопасности тоже очень важен и много делает.Ознакомься с этим:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Attack Surface Reduction
========================The most fundamental defense against security exploits is to reduce the areas of the kernel that can be used to redirect execution. This ranges from limiting the exposed APIs available to userspace, making in-kernel APIs hard to use incorrectly, minimizing the areas of writable kernel memory, etc.
Strict kernel memory permissions
--------------------------------When all of kernel memory is writable, it becomes trivial for attacks to redirect execution flow. To reduce the availability of these targets the kernel needs to protect its memory with a tight set of permissions.
Executable code and read-only data must not be writable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Any areas of the kernel with executable memory must not be writable. While this obviously includes the kernel text itself, we must consider all additional places too: kernel modules, JIT memory, etc. (There are temporary exceptions to this rule to support things like instruction alternatives, breakpoints, kprobes, etc. If these must exist in a kernel, they are implemented in a way where the memory is temporarily made writable during the update, and then returned to the original
permissions.)In support of this are ``CONFIG_STRICT_KERNEL_RWX`` and
``CONFIG_STRICT_MODULE_RWX``, which seek to make sure that code is not writable, data is not executable, and read-only data is neither writable nor executable.Most architectures have these options on by default and not user selectable. For some architectures like arm that wish to have these be selectable, the architecture Kconfig can select ARCH_OPTIONAL_KERNEL_RWX to enable a Kconfig prompt. ``CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT`` determines the default setting when ARCH_OPTIONAL_KERNEL_RWX is enabled.
Function pointers and sensitive variables must not be writable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Vast areas of kernel memory contain function pointers that are looked up by the kernel and used to continue execution (e.g. descriptor/vector tables, file/network/etc operation structures, etc). The number of these variables must be reduced to an absolute minimum.
Many such variables can be made read-only by setting them "const"
so that they live in the .rodata section instead of the .data section of the kernel, gaining the protection of the kernel's strict memory permissions as described above.For variables that are initialized once at ``__init`` time, these can be marked with the (new and under development) ``__ro_after_init`` attribute.
What remains are variables that are updated rarely (e.g. GDT). These will need another infrastructure (similar to the temporary exceptions made to kernel code mentioned above) that allow them to spend the rest of their lifetime read-only. (For example, when being updated, only the CPU thread performing the update would be given uninterruptible write access to the memory.)
.....Memory integrity
================There are many memory structures in the kernel that are regularly abused to gain execution control during an attack, By far the most commonly understood is that of the stack buffer overflow in which the return address stored on the stack is overwritten. Many other examples of this kind of attack exist, and protections exist to defend against them.
Stack buffer overflow
---------------------The classic stack buffer overflow involves writing past the expected end of a variable stored on the stack, ultimately writing a controlled value to the stack frame's stored return address. The most widely used defense is the presence of a stack canary between the stack variables and the return address (``CONFIG_STACKPROTECTOR``), which is verified just before the function returns. Other defenses include things like shadow stacks.
Stack depth overflow
--------------------A less well understood attack is using a bug that triggers the
kernel to consume stack memory with deep function calls or large stack allocations. With this attack it is possible to write beyond the end of the kernel's preallocated stack space and into sensitive structures. Two important changes need to be made for better protections: moving the sensitive thread_info structure elsewhere, and adding a faulting memory hole at the bottom of the stack to catch these overflows.Heap memory integrity
---------------------The structures used to track heap free lists can be sanity-checked during allocation and freeing to make sure they aren't being used to manipulate other memory areas.
Counter integrity
-----------------Many places in the kernel use atomic counters to track object references or perform similar lifetime management. When these counters can be made to wrap (over or under) this traditionally exposes a use-after-free flaw. By trapping atomic wrapping, this class of bug vanishes.
Size calculation overflow detection
-----------------------------------Similar to counter overflow, integer overflows (usually size calculations) need to be detected at runtime to kill this class of bug, which traditionally leads to being able to write past the end of kernel buffers.
.....
> В UNIX гарантия безопасности идёт от среды исполненияКак я вижу, эта гарантия прекрасно работает (нет)
Гарантия работает.Проблема в том, что дистрибутивы не включают опции безопасности по умолчанию. Потому, что опции безопасности чуть тормозят систему и кривописаный, дырявый сишный код перестаёт работать и JIT работать не будет. Причём при падении выводится хороший трейс с описанием всех адресов, функций и причин падения, остаётся только профиксить дыру, но им лень.
> кривописаный, дырявый сишный код перестаёт работатьТо есть, весь сишный код.
В 2000-ных годах сишный код был хорошо причесан. Главное чтобы компилятор и линковщик с безопасными опциями сишный код собрали. Да, для этого надо потрудиться и правильно его написать, хотя бы в части позиционной независимости (PIC), ROREL и возможности сборки без JIT (configure --jitless). Сегодня все готово благодаря Debian Adamantix и Gentoo Hardened.Есть пару пакетов, которые до сих пор не работают в защищённом режиме: firefox, kwin_wayland, polkitd, ... систему можно собрать и без них.
Ну вот, а говорили надо всё самое распоследнее ставить, а оно вон как.
Вообще-то САМЫЕ последние как раз таки пофикшены. А так то если некромансить, луче Win95 сразу взять. Вы вообще когда последний раз хакера под нее видели?
Тогда уж 2.6, отполированное до блеска.
Э не, под него может случайно откопаться какой-нибудь некромант троянивший этот винтаж, такого поди до сих пор еще на сетевых железках водится. А вот win95 уже даже их наверное не интересует.Впрочем если ты возьмешь какой-нибудь 2.6.9 или какой там самый первый в гите, есть надежды что их черная магия все же на этом не сработает в силу динамичного развития системы. Не окжется в системе атакуемой фичи - и опачки.
> Тогда уж 2.6, отполированное до блеска.ога, sysinfo() туда завезли именно для твоей безопасности и анонимности
Вот я не всегда согласен с Фракталом, но если кого и следуют уважать за стабильность, то это Фрактал! Остальные - жалкие.
Фрактал поди вообще програмить не умеет. Кто бы сомневался что если нет кода то и дыр нет.
Для комментирования это только не нужно, но и вредно.
Стабильные, но ненужные извержения.
Он просто толстый тролль 80 лвл
Опять линукс барахлит
барахлит то что работает и это чинится, а некро не работает в принципе, так что идите за придворным некромантом оживлять ваш уиндовз :)
Это печально, но можно сделать какие-то выводы:
- даже у разработчиков ядра иногда недостаточно компетености чтобы не допускать ошибок с памятью
- ошибки не находятся утилитами вроде Valgrind или их не используют
- ошибки живут в ядре годами; в этой заметке не указано, но в рассылке для CVE-2021-3347 предположили что она с 2008 года - еще чуть-чуть и стала бы совершеннолетней (https://www.openwall.com/lists/oss-security/2021/01/29/3)- ядру явно не хватает божественных кодеров с опеннета которые никогда не ошибаются!
Я бы посмотрел на твою компетентность при работе над условным механизмом с миллионом гаек и шестеренок которые меняют положение каждый день, и как бы ты искал то, что криво работает.
Разумеется ее недостаточно! Но люди не умеет все и сразу.
Вот ты вернешься (хехе, если))) к накосячевшему хирургу, а он такой "посмотрел бы я на твою компетентность". Забавно будет, да?А сложность этого механизма давно превзошла определенные рамки.
Что даже его авторы не могут его писать без ошибок.
> Вот ты вернешься (хехе, если))) к накосячевшему хирургу, а он такой "посмотрел
> бы я на твою компетентность". Забавно будет, да?В принципе и такое тоже бывает. Вон в ком-то салфетки забыли, а в ком-то вообще пинцет. Так что програмеры линя пожалуй не такие уж и плохие.
> А сложность этого механизма давно превзошла определенные рамки.
> Что даже его авторы не могут его писать без ошибок.Ну так удачи кому-то еще выехать на белом коне и сделать лучше. Только это, лысая ось без фич и с поганым перфомансом даром никому не надо, а когда вы попробуете столько же фич с тем же перфомансом - большой вопрос что получится у вас...
>с поганым перфомансомИнтересно что вы перфоманс приплели к линуксу. Он этим никогда не славился.
А подумать вначале? Не, не слышали.
Ну ВСё!
Сейчас перепишут на расте и проблема устранена
Невозможно... На расте даже вызов ядра невозможно сделать.
А в Мозиле растаманы 15 лет писали-писали, писали-писали... И потом их уволили.
Безопасность ставит под угрозу работоспособность компании под АНБ.
лучше на алгоритмическом языке... или на языке 1С :)
вот были же и есть замечательные языки: Ada, Algol, Fortran, Prolod, Forth
вместо эти хайпероподелий и криво..оппа недоделок лучше бы приложили усилия в развитии этих технологий.
Ведь тот же пролог и форт уникальны и имели и до сих пор имеют большое будущее.
а как же рая и рапира?
Форт вообще чудо, не прибит гвоздями ни к одной идеологии, но позволяет писать в любой парадигме. А из-за особенностей словаря программы получаются на порядок короче.> Ada, Algol, Fortran, Prolod, Forth
У этих языков фатальный недостаток: "придуманы не растаманами". Компиляторы отточены, библиотек уже море написано, как будешь имитировать бурную деятельность?! То ли дело раст - непаханое поле, в одной только Мозиле стулья протирали 15 лет с нулевым результатом.
Прибит к польской обратной бесскобочной арифметике.
И это классно! Ты же не жалуешься, что в расте нельзя использовать польскую арифметику?
Я не растаман, поэтому на Раст мне фиолетово. А в остальных случаях, я привык видеть арифметические выражения, записанные привычным образом.
Кто? Нынешняя школота?) Ха! Напомню про Hurd нопример..
А знаешь почему ? Потому что хурд не на русте !
Тут лучше хронологию вспомнить, что Линусу потребовалось меньше года от идеи до выпуска первой версии линух, а растаманы уже 15 лет т*ются и до сих пор проблемы с запуском на реальном железе. Поэтому хоть на расте пиши хурд - ничего не выйдет.
Забавно натыкаться на такие вот треды, где растохейтеры дружно массируют друг друга в интимных местах. Один вбросил, другой подхватил, третий на это потеребил и поставил плюсик. Дружная такая компания - считай, комюнити. Даже диалект свой придумали - "хруст" и тому подобные кривляния уровня детского сада. Сами набрасывают говно на вентиллятор (а это именно оно, что видно из аргументации типа "хруст не может даже вызвать ядро"), а потом жалуются на то, как их задолбали вездесущие растоманы. Гениально.
Крестовики и минусовки опять буферы свои порвали.
Это партизаны от растаманов специально так делают.
Как говорится... одной дырой больше, одной дырой меньше... да какая разница для дырявых
какая разница если патчи давно вышли и все обновились