Sure, but Ubuntu ships with a million things. Windows only ships with Paint, Notepad, and Calculator. Notepad has a million bugs that have been around since Windows 1.
Sure, but Ubuntu ships with a million things. Windows only ships with Paint, Notepad, and Calculator. Notepad has a million bugs that have been around since Windows 1.
You are just fishing at this point. What does notepad have anything to do with system stability of a third-party application? Notepad could have a million bugs, literally, and I wouldn't give it a second thought.
If you want to excuse Linux for any shortcoming of its main development tool, I can surely agree. But that you refuse to grace other operating systems with the same leniency is... what's the word you used?... unfair.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I'm just drawing a parallel. My point is, by the logic of "Linux is bad because there's a GCC bug", we can also say that "Windows is bad because Notepad is buggy."
Since the second statement doesn't make sense, I'm using it to show how the similar first statement doesn't make sense either.
Well, yeah. But notepad? Really?
Don't think visual c++ isn't without bugs. You could have drawn the parallel right there. In any case, "Linux is bad because there's a GCC bug" is not how I read it. Instead it was "Hey, Linux can also segfault. Don't be fooled."
You have to confess though, that exactly because you were drawn to that conclusion is the result how windows bsods have been generally treated; i.e. in a misleading way that tries to attribute the cause to the operating system itself.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I may be wrong, but I remember many things could cause a BSOD, in userland. That would be an OS bug, because a modern OS shouldn't allow a userland application, no matter how badly written, to crash the system.
A BSOD would be the parallel of a kernel panic on Linux, which, while not unheard of, is certainly a lot less common than BSODs.
But then of course, Windows BSODs are mostly caused by buggy drivers. Linux drivers (at least the in-kernel ones, and most of them are) are typically higher quality, because they need to be open sourced, and go through a bunch of code review. And we are back to the muddy water again... Should Windows be responsible for buggy third-party drivers?
All the way to before Windows NT, they could. Perhaps the reason why BSODs in windows retain to this day their infamous reputation. But ever since Windows 2000 that is no longer the case. BSODs are strictly, as you say, the exact same of kernel panic errors on Linux.
Well, should Linux? Admitting the existence of badly written Linux drivers, is the only step you need to answer your own question.But then of course, Windows BSODs are mostly caused by buggy drivers. Linux drivers (at least the in-kernel ones, and most of them are) are typically higher quality, because they need to be open sourced, and go through a bunch of code review. And we are back to the muddy water again... Should Windows be responsible for buggy third-party drivers?
But, if you want my opinion; No, of course, not.
And do not be entirely sure either with your assumption than just because Windows drivers aren't peer-reviewed this means they are of a lesser quality. It's about time this false belief in peer-review as the effigy of excellence in code design is put to a rest. I should not need to call your attention to the fact that open source peer-reviewed software in general suffers from exactly the same issues with bugs of any other closed source software. Or that no one can claim one development model of being better than the other on this regard without hard factual data... which simply doesn't exist. I'll let you know this though: I can't remember the last time I had a driver-based bugcheck on Windows.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
All the way to before Windows NT, they could.You are starting to sound like Elysia.But ever since Windows 2000 that is no longer the case.
The code that originates a "BSOD" can indeed be found in "userland".
So, you are right in that they are exactly like a kernel panic.
Any user level code that calls a function which in turn calls kernel level code can crash the system. This has been a known issue with a few "Windows XP" shared libraries from the moment it dropped. To this day, sending the right parameters in the right context gives you an instant "BSOD".
Soma
FYI, I didn't consider for the purpose of this discussion "userland" as including drivers code, simply because I took cyberfish use of "userland" as an obvious mistake he probably didn't intend to. However, and this is the clarification I made, before windows 2000, user programs could cause bsods by doing simple things as not checking if a driver was installed before trying to access it. That is no longer the case.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
*shrug*as an obvious mistake he probably didn't intend to
So... then your mistake is assuming I intended anything other than user level code running as an unprivileged user?
All joking aside, I'm not talking about drivers, global hooks, or privileged API, and the problem I'm talking about absolutely still exists. Considering Microsoft's standpoint on "Windows XP", I'm sure it always will.
Any unprivileged user code that calls one of a few normal, documented API in certain contexts achieved by accident or ill intent will call an undocumented kernel routine with invalid parameters which will put the system into an invalid state which will result in a "BSOD".
Rings and privileges only protect the system from user level unprivileged code and from other user level unprivileged code in so far as the system is perfectly designed and bug free. That simply isn't the case for any operating system.
Or, to put it another way, rings and privileges don't protect the system from itself.
Soma
Nope. But I can see your point now. Look back at cyberfish post. It's that second paragraph of his that is misleading. Care to review that?
His second paragraph leads me to believe he means windows BSODs are different than Linux kernels panic. They actually used to be different, in that pre-NT BSODs could be generated without a bugcheck. At which time BSODs were indeed way common. But they aren't anymore. Only bugchecks can generate BSODs. Meanwhile, userland can generate bugchecks, that much we agree.I may be wrong, but I remember many things could cause a BSOD, in userland. That would be an OS bug, because a modern OS shouldn't allow a userland application, no matter how badly written, to crash the system.
A BSOD would be the parallel of a kernel panic on Linux, which, while not unheard of, is certainly a lot less common than BSODs.
But it's also in this context that his use of "userland" makes no sense. If Windows BSODs where in fact different, but exclusively in userland, what then does he think actually differentiated BSODs from kernels panic? So I just assumed the use of "userland" is a probable mistake.
My mistake was probably not having thought better at what to quote when answering that. The first phrase just seemed adequate at the time.
Last edited by Mario F.; 06-02-2011 at 08:36 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
O_o
LOL
Dude. That bit I quoted and the response really was a joke. And the other bit wasn't even targeted it you. I was poking Elysia for his common tactic of assuming that Microsoft's interpretation of "correct" is an appropriate one.
I did misunderstand what you'd claimed though...
*shrug*
Soma
By userland I meant non-kernel and non-drivers. Drivers are a different issue. IMHO they should be allowed to crash the system (ie. the kernel shouldn't need to be designed to guard against bad drivers, since they run in kernel-land, with some exceptions like libusb and fuse).
I'm not saying peer-review will catch all bugs or automatically produce better code than a closed-source model.
I'm only saying all the code that goes into the kernel have to meet a certain standard that is set quite high. It's very hard to get code accepted into mainline kernel.
On Windows, a lot of drivers out there, especially from smaller companies, clearly aren't written to anywhere near that kind of standard.
Driver-induced kernel panics aren't unheard of (though I have never experienced one), but I have personally experienced about a dozen driver-induced BSODs already, over the past few years.
You know, there is a tool from Microsoft called Driver Verifier or something, that will check to make sure your driver is of high quality. Furthermore, to even put them in the kernel, they need to be signed. And then there's the WHQL thingy. Plenty of opportunity to make sure drivers are well written. Just saying there are tools to make sure drivers are of high quality, developers willing...
Drivers should not be allowed to crash the system. Typically, if a driver fails, the driver could simply be restarted, the device reinitialized, and the system going back to a normal state again.
Unfortunately, since both Microsoft and Linux thought it a good idea to write monolithic kernels where drivers run in kernel mode and not user mode, that's probably not something we're ever going to see.