Поддержка сопрограмм (coroutines) и continuations в Ruby

https://web.archive.org/web/20071024123936/http://www.ruby-forum.com/topic/126011

http://www.rubydoc.info/stdlib/core/1.9.2/Fiber

http://ruby-doc.org/core-2.3.0/Fiber.html

http://ruby-doc.com/docs/ProgrammingRuby/html/ref_c_continuation.html

http://ruby-doc.com/docs/ProgrammingRuby/html/ref_m_kernel.html#Kernel.callcc

K - #Kernel
L - #Linux

http://turnoff.us/image/en/sql-server-on-linux.png

http://turnoff.us/geek/sql-server-on-linux/

The drama around Rust drivers inclusion into Linux kernel became worser and even worser.

Old kernel maintainer against of Rust code inclusion into DMA for drivers.
Asahi Linux maintainer resigned from Linux kernel maintainers.

The question is - what is better, maintain two languages and handle this complexity, one of it, Rust, provided memory safety, when usafe blocks are strictly located and controlled, or, continue to maintain old (and new) error prone code in C language with all that memory safety issues, as it was before, for many years, without accepting new approaches to develop safe system software, drivers and kernel modules.

Overall, that's the problem of old minded people, who doesn't want to put the efforts to accept something new, which can be better than old approach.

I've got only one question - if there are so much resistance from old minded people, kernel maintainers, for what the Rust for Linux subsystem was even included into the kernel, what old kernel maintainers and Linus himself expected when they've done that, i.e. introduction of Rust subsystem into kernel? They want to keeping it in cage of just subsystem for drivers development, when the problem is the whole old approach to memory management?

If this situation will be progressing (and it will!) many new wave kernel maintainers and kernel developers will leave and resign from Linux kernel. And that's not good for Linux, as maintainers became older and older and it's became tremendously hard to involve new generation of system developers into kernel development and maintenance.
Many new wouldn't even join Linux kernel, because of such toxic environment in conversations, and the better option here for new wave system developeers is to consolidate common efforts on some alternative kernel, like RedoxOS microkernel for example, which is a Unix POSIX compatible kernel, fully written in Rust, and someday, in 10-20 years from now, when Linux gets old and cost of maintenance of old error prone C code will be high (same as with assembly language kernels in previous age), Redox will became a Linux alternative, same as BSD kernels and distros, but better.

https://lore.kernel.org/lkml/20250207-rm-maint-v1-1-10f069a24f3d@marcan.st/

https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/

https://www.theregister.com/2025/02/07/linus_torvalds_rust_driver/

#Rust
#RustLang
#Linux
#kernel

Whoa! We need to update our kernels!

https://hoefler.dev/articles/vsock.html

https://security-tracker.debian.org/tracker/CVE-2025-21756

#kernel
#Linux
#VSock