On Sun, Jul 7, 2013 at 11:06 PM, Bennie Kloosteman <[email protected]> wrote: > "You think Linux is not well-engineered?" > > Nope .. its the same piece of 1970s crap that all the other popular OS use , > with trivial differences people make a bit deal about.. You really think the > difference between Vista and Linux is the kernel when you complain about > X.org ? XP ,Vista , Windows8 all basically have the same kernel some OS's > people loved others they hated but the difference is never the kernel. > Load up a copy of minwin and you can see.
Linux only emulates a traditional Unix system on the surface. There are no equivalents to features like control groups, namespaces and many other features on traditional Unix. The implementations of asynchronous I/O between operating systems are very different paradigms too (epoll/kqueue-style vs. IOCP). The epoll event loop isn't just for I/O either, since in addition to files, sockets and pipes it also handles filesystem events (inotify), signals (signalfd), timers (timerfd) and arbitrary userland notifications (eventfd). Another example of functionality moving into kernel-space is the udev/evdev/drm stack. Wayland and Mir are full replacements for X.org, but they're only a thin IPC layer on top of the kernel. > That said it doesnt matter , the fact Runtimes like rust create tasks or > services like nginx manage there own threads and memory ( and even OS do > this with file systems) , basically means the kernel just becomes a big > device driver and the apps do what they like but the kernel really should > have been doing those things long ago. Instead it was optomized for almost > batch processing applications designed in the 70 where latency was more > important than throughput . Lazily committed RAM is very useful for batch > processing. Rust uses the kernel's implementation of threads and memory management as other applications do. The userspace threads are an abstraction of the underlying event loop (layered on top of the kernel's own event handling), not a replacement for real threads with pre-emption. The scheduler only implements cooperative scheduling itself, and relies on the operating system to provide "real" pre-emptive threads. > That said i fired up uclinux for a project a few years ago ( with no VM > kernel support on 86_64 so no copy on write for fork ) so no lazy > allocation either and ran some heavy load web service like tests and it was > so much faster despite uclinux having many older algoritms / techniques.. > > Ben Virtual memory is a significant expense, but it's an expense paid to make a robust multi-tasking operating system. Lazy allocation is a convenient optimization to make when you're already paying the price needed to implement it. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
