Actually, Windows 3.1 had preemptive multitasking, but all Windows apps ran inside a single preemptively multitasked process. DOS apps ran in their own preemptively multitasked processes. This whole system was extended in Windows 95 so that each Win32 application had its own preemptively multitasked process and only Win16 apps would still share a single process. Windows 3.1 also had virtual memory, but again, since there was only one process, it was effectively used as a way to extend the amount of memory available rather than creating separate protected virtual address spaces for each application. And it was badly implemented, a problem that continued through the 9x series.
The NT is not used (or irrelevant) because modern OSes like Linux and Windows NT do not use the x86 task management mechanism. Rather, tasks and task swapping are implemented in the kernel by saving and restoring register manually. Furthermore, all interrupts use interrupt gates instead of task gates, so no x86 task switching occurs there either. On both Linux and Windows, the double fault exception, however, does use a task gate, probably to avoid any further faults which would reset the processor.
You obviously don't know anything about Old English. The plural in Old English was "dwergas", which would have developed into "dwarrows" (variations of this recorded through the Middle English period). "Dwarves" also shows up at times in more recent literature (past couple centuries) alongside the more common "dwarfs".
From Wikipedia:
"Scheme started as an attempt to understand Carl Hewitt's Actor model.[1] Scheme was originally called "Schemer", in the tradition of other Lisp-derived languages like Planner or Conniver. The current name resulted from the authors' use of the ITS operating system, which limited filenames to two components of at most six characters each. Currently, "Schemer" is commonly used to refer to a Scheme programmer."
I think you miss the point. There is no objective way to say whether some prediction is right or wrong. The only means to judge correctness (or even make observations in the first place) are based on the terms proposed by the model. So scientific theories are effectively circular arguments that are probably right (because the universe probably isn't malicious), but can't be guaranteed to be right.
> (hint to grandparent, it contains the word "falsifiable").
Or not. You can't really say science is objectively falsifiable because that requires a framework in the first place by which you can accurately judge correctness. But since a scientific theory is the only framework you get, what ends up happening is that falsifiability is couched in terms of the existing theory, which is no good.
That's fine for open-source software already in repositories and patched to work with the distro. For everything else, especially closed-source 3rd party apps, this is just not an option. If people want to have real corporations write real software instead of the current collection of half-working, half-featured apps that exists on Linux today, the game of "let's break the ABI!" needs to stop.
Microsoft isn't the one changing APIs and breaking things all the time. They've bent over backwards to make sure that the APIs remain backwards compatible while gaining new features. It's on Linux that you see APIs and even ABIs break with every other release of some library or other critical package. What makes Wine hard to do is that it is very difficult to reverse-engineer the inner workings of an entire API for another operating system AND make sure that it's bug-for-bug compatible. Only testing can make that work and that's a very slow and painstaking process.
You don't have to do a scavenger hunt on Linux. If there's a driver available, it's included in the kernel or in the distribution. I installed SuSE 10.1 on my ThinkPad T43 and it autodetected and configured everything and I mean everything.
That's not the issue. The issue is that the toolkits are inefficient in their usage of the X protocol. This is partially if not totally because of the crapfest that is xlib. Xlib is so terribly inefficient and poorly designed that even the best-written toolkit will have some performance problems if it uses xlib. With XCB now getting ready to go primetime, performance with X might finally start to improve.
You don't understand what modular means in this case. It only means that the various components of X are now in separate autotooled packages. There hasn't been any change in the existing modules, only now they are available separately rather than as part of a single monolithic tarball with a monolithic build system.
Why do you need TC? Why not just have an OS that uses a real security model with capabilities and the like? That would solve so many problems, especially since such systems are provably correct.
Slashdot Mirror
Actually, Windows 3.1 had preemptive multitasking, but all Windows apps ran inside a single preemptively multitasked process. DOS apps ran in their own preemptively multitasked processes. This whole system was extended in Windows 95 so that each Win32 application had its own preemptively multitasked process and only Win16 apps would still share a single process. Windows 3.1 also had virtual memory, but again, since there was only one process, it was effectively used as a way to extend the amount of memory available rather than creating separate protected virtual address spaces for each application. And it was badly implemented, a problem that continued through the 9x series.
The NT is not used (or irrelevant) because modern OSes like Linux and Windows NT do not use the x86 task management mechanism. Rather, tasks and task swapping are implemented in the kernel by saving and restoring register manually. Furthermore, all interrupts use interrupt gates instead of task gates, so no x86 task switching occurs there either. On both Linux and Windows, the double fault exception, however, does use a task gate, probably to avoid any further faults which would reset the processor.
That's not what he meant. He meant having the actual displayed prompt show the current path, like the Fedora prompt: [user@host /usr/bin]$
No. Either "octopuses" or "octopodes".
No it shouldn't.
KParts
Umm, no. You need read your intro OS textbook again. root and ring-0 have nothing to do with each other.
You obviously don't know anything about Old English. The plural in Old English was "dwergas", which would have developed into "dwarrows" (variations of this recorded through the Middle English period). "Dwarves" also shows up at times in more recent literature (past couple centuries) alongside the more common "dwarfs".
From Wikipedia: "Scheme started as an attempt to understand Carl Hewitt's Actor model.[1] Scheme was originally called "Schemer", in the tradition of other Lisp-derived languages like Planner or Conniver. The current name resulted from the authors' use of the ITS operating system, which limited filenames to two components of at most six characters each. Currently, "Schemer" is commonly used to refer to a Scheme programmer."
Why are you disagreeing with him? Everything you said agrees with what he said.
I think you miss the point. There is no objective way to say whether some prediction is right or wrong. The only means to judge correctness (or even make observations in the first place) are based on the terms proposed by the model. So scientific theories are effectively circular arguments that are probably right (because the universe probably isn't malicious), but can't be guaranteed to be right.
> (hint to grandparent, it contains the word "falsifiable"). Or not. You can't really say science is objectively falsifiable because that requires a framework in the first place by which you can accurately judge correctness. But since a scientific theory is the only framework you get, what ends up happening is that falsifiability is couched in terms of the existing theory, which is no good.
It's kinda complicated: http://blogs.msdn.com/oldnewthing/archive/2006/03/ 30/564809.aspx
That's fine for open-source software already in repositories and patched to work with the distro. For everything else, especially closed-source 3rd party apps, this is just not an option. If people want to have real corporations write real software instead of the current collection of half-working, half-featured apps that exists on Linux today, the game of "let's break the ABI!" needs to stop.
Microsoft isn't the one changing APIs and breaking things all the time. They've bent over backwards to make sure that the APIs remain backwards compatible while gaining new features. It's on Linux that you see APIs and even ABIs break with every other release of some library or other critical package. What makes Wine hard to do is that it is very difficult to reverse-engineer the inner workings of an entire API for another operating system AND make sure that it's bug-for-bug compatible. Only testing can make that work and that's a very slow and painstaking process.
You don't have to do a scavenger hunt on Linux. If there's a driver available, it's included in the kernel or in the distribution. I installed SuSE 10.1 on my ThinkPad T43 and it autodetected and configured everything and I mean everything.
Let's just let Keith Packard do the talking: http://keithp.com/~keithp/talks/usenix2000/render. html
That's not the issue. The issue is that the toolkits are inefficient in their usage of the X protocol. This is partially if not totally because of the crapfest that is xlib. Xlib is so terribly inefficient and poorly designed that even the best-written toolkit will have some performance problems if it uses xlib. With XCB now getting ready to go primetime, performance with X might finally start to improve.
You don't understand what modular means in this case. It only means that the various components of X are now in separate autotooled packages. There hasn't been any change in the existing modules, only now they are available separately rather than as part of a single monolithic tarball with a monolithic build system.
Why do you need TC? Why not just have an OS that uses a real security model with capabilities and the like? That would solve so many problems, especially since such systems are provably correct.