Come fly with me
But be careful of the accommodation when you get there
Printable View
Hmm... I didn't relate to the Linux Airways. I'd think is more like:
Linux Air
Using Linux Air is generally a guarantee that you will reach your destination safe and with all the luggage. However it is expected you know how to operate, fly and build airplanes. During flight, the airplane will sometimes cease to work, the pilot will quit or the stewards will start a discussion between themselves. It's your own responsibility to take anyone's place and either, fix the plane, take the controls, or join the discussion. If you do none of these things, Linux Air is not responsible for the quality of your trip and it's your own damn fault if you don't like it.
Seen at an airport...
Attachment 10551
Hahaha very good
If you decide to fly with Linux Air you should be very careful. Never use the newly-opened routes.
Ubuntu 11.04 Is Buggy..Even the Fanboys Agree.... - comp.os.linux.advocacy | Google Groups
Maybe a bit too harsh on Windows Air, but then again BSODs are so infamous...
I have been a fan of Ubuntu since its inception, and normally have it running on at least one of my machines.
After the 11.04 release the machine it was running on is now running Debian.
Bad.. just bad.
Yeah, I've been hearing that Gnome 3 was not met well by many a Ubuntu user. It's kind of ironic that the Gnome team didn't look around them to learn from previous experiences concerning dramatic changes to a GUI and how this can negatively affect a sizable portion of their userbase. I mean, it's like they like to do the exact same mistakes as their nemesis, the Windows operating system. But above all, the fact these changes are introduced in the faces of users, without much in the way of opting out from certain (and obviously arguable) decisions, like removing the minimize button from windows. Moreover, Ubuntu's own team very weird decision to not give the user an option for Unity 2D out of the box... maybe they think Linux GPU driver support has matured enough to make Unity 3D a no-brainer installation on every user machine (excuse me, I'm smirking at this point. How rude of me).
That said, 11.04 is an "meantime" release, is that right? So let's wait for the next LTS before passing final judgment. I installed Gnome 3 on my Archlinux for a test-drive and I actually found it visually appealing. But this is definitely an immature GUI at this stage. Could never replace OpenBox on my machine.
Smirking??? I'm laughing my .......... off! I can't even use my GPU because it fails to show anything at all. I have to resort to using my integrated GPU after spending $50, which is annoying, needless to say. The kicker: I didn't even want the thing for graphics, I wanted to play with CUDA/OpenCL.Quote:
Originally Posted by Mario F.
Very much so....I was shocked after seeing(&&trying to get everything working) @the new Fedora release..Quote:
f you decide to fly with Linux Air you should be very careful. Never use the newly-opened routes.
I'm usually a Linux fanboy, but to be fair, I saw a kernel panic on a 747 once, on the personal entertainment system or whatever they call that (touch screen in front of every seat).
PS. This is not an analogy. It's real.
That's not fair. That's just GCC.
It's like attributing a Firefox bug to Windows because it runs on Windows.
It ships default with Ubuntu. It's more like attributing a Windows' C++ STL bug to Windows because it's the fault of a library that ships with it.
Well, you may find it unfair but it still leads to the same place; stability is often the programmer's responsibility. I can name two of the most common reasons why anyone in the world gets BSODs on windows, and none has anything to do with the operating system. Still Windows' blue screens of death have pretty much become a meme pointing at this operating system supposed deficiencies that is simply doesn't have.Quote:
Originally Posted by cyberfish
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.
Who uses notepad?Quote:
Originally Posted by cyberfish
Everyone, or more specifically, everyone who uses a program that relies on the STL, which is about everyone, uses the STL.
Clearly, when considered within the context of which is more used, a bug in one is equal to a infinitude in the other.
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.Quote:
Originally Posted by cyberfish
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.
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.
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.Quote:
Originally Posted by cyberfish
Well, should Linux? Admitting the existence of badly written Linux drivers, is the only step you need to answer your own question.Quote:
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.
Quote:
All the way to before Windows NT, they could.
You are starting to sound like Elysia.Quote:
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.
*shrug*Quote:
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?Quote:
Originally Posted by phantomotap
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.Quote:
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.
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.
It would be nice if there's a program that can read some code and tell you how good the code is...
By high quality I mean not buggy. I don't think there's any tool that can check for that.
For me, I have seen numerous BSODs by the audio driver, video card driver, and disk controller.
I agree drivers should be in userland as much as possible, but like you pointed out, that's not the case right now with any major OS. Though libusb and fuse are going in the direction to change that. They also have a worthy goal of allowing drivers to be cross-platform. Unfortunately they are both weakly supported on Windows. NDIS is also somewhat similar.