>From what I gather, you only really use Windows... yet you're trying to argue about Unix-like systems. They are not even similar to Windows at all, so your attempt to argue that in fact they're all the same is amusing... and saddening. I didn't switch away from Windows because I grew a neckbeard or anything. It was for practical reasons that applied to me, and because the other options had massive advantages (for me, personally) over Windows. If they were so similar, I would have gained nothing from switching. You're probably happiest with what Windows offers, and that's perfectly fine, but the differences between Windows and Linux/BSD/Solaris/OSX are far from superficial.
More on topic though, all of this stuff is being handled (naturally) on a platform by platform basis as Graydon pointed out. Therefore, this whole thread seems moot. I think very little remains to be said on the subject of this thread. On Jul 7, 2013 10: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. > > 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. > > 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 > > > On Mon, Jul 8, 2013 at 5:21 AM, Josh Leverette <[email protected]> wrote: > >> You think Linux is not well-engineered? That statement just took the wind >> out of your sails. There are components that run *on top of *Linux (and >> similar Unix-like systems) that are poorly engineered, X.org chief among >> them, but that doesn't make the Linux kernel poorly engineered. Making >> intangible claims about Linux being both poorly designed and transient is a >> quick way to make your opinions fall into disregard. This is not the place >> for such a discussion, and I've never seen any substantive evidence to back >> up that train of thought. In fact, I don't think anyone has seen >> substantive evidence to back up that train of thought. >> >> Lazily committed RAM is useful, and the logic behind "resource X is >> plentiful, therefore use it liberally" is the same logic that resulted in >> something we now know as Windows Vista. Hey, RAM is getting so big these >> days, why not use more of it! >> >> There are edge cases that can cause problems with Lazy Commit, but you >> really believe there aren't worse problems with a non-Lazy Commit system? >> The grass isn't greener on the other side, unless you live in an edge >> case... and that's a strange place to live. >> >> >> On Sun, Jul 7, 2013 at 4:01 PM, james <[email protected]>wrote: >> >>> On 05/07/2013 23:05, Daniel Micay wrote: >>> >>> On Fri, Jul 5, 2013 at 5:43 PM, james <[email protected]> >>> <[email protected]> wrote: >>> >>> > On 05/07/2013 08:37, Graydon Hoare wrote: >>> >>> >>>> I agree that it's higher than it seems it "needs to be". But it >>> will>> always be unnecessary overhead on x64; it really makes no sense >>> there. The>> address space is enormous and it's all lazily committed. >>> >>> >>> I don't think you can rely on 'lazily committed'. Not on a system >>> that is> properly engineered anyway. >>> >>> You can rely on it, it's the standard behaviour on Linux. The actual >>> consumed memory will be equal to the size of the pages that have been >>> touched. >>> >>> And that was entirely my point. As a Solaris programmer I thought the >>> lazy assignment and overcommit was a stupid idea on AIX and its still a >>> stupid idea on Linux. There is no good reason for an operating system to >>> fail a process for accessing memory that it has been told it can have, nor >>> for a process to be terminated because some other process uses memory. Its >>> not well-engineered, quite the opposite. And its particularly pointless >>> given that space is so cheap. Its not as if you have to actually wire up >>> backing store, or even wire up page tables - but you do have to make sure >>> that enough resources are available to make sure that you can do so later >>> on demand and won't run out. Preferably using swap that doesn't deadlock >>> when you try to use it. I don't think Linux is well engineered, and I >>> don't think the development process (if that word actually applies) will >>> ever fix its deficiencies. Even if it is standard on Linux, its a really >>> poor idea to assume thet the whole world does now and will continue to use >>> Linux as the only base for doing useful computing. >>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> >> -- >> Sincerely, >> Josh >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
