Re:I don't know if I fully agree with that
on
Fire Your IT Boss
·
· Score: 1
Unless they are managing several different types of jobs such as coding and graphics design. I think it would be unreasonable to expect someone to know how to do both.
I don't see why a manager--or, indeed, anyone--can't have at least a basic grasp of graphic design (and color theory, etc.) as well as programming. Hell, I do. I'm not very good at the graphic design part, but I understand it, and that's the important part.
I missed no point when reading your half-baked idea; your point is simply a poor one. The end user experience is head-and-shoulders above all other issues in importance. There are times when crash bugs are in the "yeah, it'd be nice if we could fix it, but we don't have the time" category, and in the real world people have deadlines. Seamless recovery turns what would otherwise be often-annoying problems into "meh" problems for the only people who matter: the end users. If you can alleviate problems, you do it, even if it's not a complete fix, because your end users want as seamless a product as can be made and your job is to cater to them. If you aren't doing as good a job at catering to the end user as the next guy, you will and deserve to fail.
Hasn't Windows taught you anything? It only has to be good-enough and simple enough to bring back to life when it screws up. That's it. Seamless recovery makes this process far simpler and far more effective.
And if you think all crash bugs are security flaws based on the logic you've expressed above ("if X, then I might as well assume Y without any proof" is pretty shitty), I am very glad I don't work with you.
Modern managed code, either in the JVM or the CLR, JIT compiles. Calling this interpretation is kind of silly and misleading (and if you really wanted to, you could run a CLR app through ngen.exe or mono -aot, which stores a native code image along with the CIL image, giving you native code startup speed without JIT but allowing reflection and the other niceties of managed code), because in the traditional sense that people actually use it, rather than Wikipedia's definition, an interpreter would be re-interpreting similar code regularly. By that definition, you're correct...but that's a bad definition.;-)
And I don't disagree that there will be sloppy code--but you seem to be forgetting that most end users can't fix it, and the fastest way to get them back up and running is graceful failure. Yeah, it's less annoying to them. That's the point. The end user's experience is, for a web browser (and most, though obviously not all, other code), the most important thing, and not doing something to improve it under the guise of "getting websites fixed" is shirking the responsibility to provide the end user with the best possible experience.
You're right, of course. Off-the-cuff and all that.
In my defense, though, it should not, however, return unless everybody else has ceded time, too. So it might make your laptop angry, but other than that it isn't much of an issue.:)
I know. I was being a tongue-in-cheek asshole.:) An unpleasantly large number of computer scientists I know think you really can bash out every bug, though. The real world is not high on their list of priorities.
Apple *had* an X server implementation when they started futzing with NeXT. They *fled* from using it as the core of their desktop, and for good reason.
And no, douchebag, I don't consider "server infrastructure" to be file browsers or window managers. Trying to write a performant graphics driver for X.org (which is the only X server that really matters, in a desktop context; Xming for Windows, as you alluded to, can't do most of what a modern desktop should be able to, though it's useful for a few tasks) requires you to rip out the lower third of the fucking server and wedge in custom code for it. Linux Hater Blog has an excellent explanation, for the people who don't know what they're talking about (that'd be you, champ): http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on-open-source.html
As for memory access violations: by far the most common segfault I see is dereferencing a null pointer, which I don't think you can really call a security weakness--just sloppy code.
I forgot about longjmp, my bad. That said, with longjmp you can come back from it, *sort of*, but as you said, you can't really guarantee program state, and so that's not really very useful.
You can catch exceptions in c++ threads you know, and if you catch SEH exceptions you're catching the same exceptions as.NET apps do. So, its the platform that matters to get such stability, not the programming environment.
Go cause a segfault and catch the resulting exception, please. Oh, wait...
(No, signal handling doesn't count, if only because it can't be done on Windows, and if it doesn't work on Windows your web browser has a real tiny market share.)
Firefox has done an absolute shit job. Right now, Firefox is, full-stop, the worst browser out there.
For that matter, IE8 already does what Chrome does. The browsers that don't are Konqueror, Firefox, Safari, and Opera (plus the assorted little browsers not worthy of mention. Get a clue.
IE8 will be performing well, and Firefox is going to have their balls in a vise, crushed by Chrome and IE8.
If you can't fix every bug--and you can't, so don't troll and say you can--graceful recovery is the next best thing. We live in the real world, not the computer scientist's world of "code can be perfect."
There are edge cases where HTML will crash IE (or used to), and I remember some cases that would kill Gecko.
JavaScript is an extremely gnarly language to actually implement (most prototype-based languages are), and it's very difficult to stomp on all the bugs. There are also cases where an infinite loop in the JavaScript can wedge the browser, which this alleviates.
Plugins are a major issue, and that's almost certainly the next thing to be put in its own process.
Keep in mind that yeah, there are bugs in browsers, and they should be stomped on--but you can't get them all, and graceful recovery is still great to have.
...whaaaaaaaat? Microsoft and Apple have moved *away* from X11 window systems. Because they completely fucking suck for desktop use. To get any reasonable desktop performance out of X, you have to replace about half of the server infrastructure (and anyone who thinks the way X.org is designed is *good* should please stop using computers).
People are not moving back to the processes-are-better view, either. In *this* case, processes have some benefits because they provide a greater amount of firewalling in case of crashes, because stability is the primary concern of a web browser these days (we've achieved good-enough performance). Threads are still better for the majority of computing tasks, if only due to shared address space (because IPC sucks to write and debug).
This really is important to remember. WinNT processes *are* slow, but not *that* slow anymore. (In the NT 3.5 days, on the other hand, a process could take tenths of a second to start up.)
WinNT processes are still slow, but a lot faster than they used to be. I don't have numbers offhand, but processes are not as expensive as they used to be (and you've got better hardware, too).
I agree with you; processes are only really a big win when you're dealing with a framework that can easily fly off the rails. Most native code falls into this category, because you generally can't even try to recover from a segfault/memory access violation, whereas Java/.NET give you the ability to at least attempt recovery. For managed code, though, threads or distributed objects (I prefer the former; they seem cleaner and more logical to me) are the way to go.
WinNT processes are considerably cheaper than they were when that was written in 2002, both because of more efficient code and faster hardware. Still slower than Unix, but the difference is not that great. (Unless you're running a really shitty antivirus, which would slow down process spawning.)
It's considerably easier to firewall a thread from taking the rest of the process down in.NET when using AppDomains, although it's still a difficult prospect and arguably more difficult to code and debug across AppDomains.
Slashdot Mirror
Unless they are managing several different types of jobs such as coding and graphics design. I think it would be unreasonable to expect someone to know how to do both.
I don't see why a manager--or, indeed, anyone--can't have at least a basic grasp of graphic design (and color theory, etc.) as well as programming. Hell, I do. I'm not very good at the graphic design part, but I understand it, and that's the important part.
I missed no point when reading your half-baked idea; your point is simply a poor one. The end user experience is head-and-shoulders above all other issues in importance. There are times when crash bugs are in the "yeah, it'd be nice if we could fix it, but we don't have the time" category, and in the real world people have deadlines. Seamless recovery turns what would otherwise be often-annoying problems into "meh" problems for the only people who matter: the end users. If you can alleviate problems, you do it, even if it's not a complete fix, because your end users want as seamless a product as can be made and your job is to cater to them. If you aren't doing as good a job at catering to the end user as the next guy, you will and deserve to fail.
Hasn't Windows taught you anything? It only has to be good-enough and simple enough to bring back to life when it screws up. That's it. Seamless recovery makes this process far simpler and far more effective.
And if you think all crash bugs are security flaws based on the logic you've expressed above ("if X, then I might as well assume Y without any proof" is pretty shitty), I am very glad I don't work with you.
Modern managed code, either in the JVM or the CLR, JIT compiles. Calling this interpretation is kind of silly and misleading (and if you really wanted to, you could run a CLR app through ngen.exe or mono -aot, which stores a native code image along with the CIL image, giving you native code startup speed without JIT but allowing reflection and the other niceties of managed code), because in the traditional sense that people actually use it, rather than Wikipedia's definition, an interpreter would be re-interpreting similar code regularly. By that definition, you're correct...but that's a bad definition. ;-)
And I don't disagree that there will be sloppy code--but you seem to be forgetting that most end users can't fix it, and the fastest way to get them back up and running is graceful failure. Yeah, it's less annoying to them. That's the point. The end user's experience is, for a web browser (and most, though obviously not all, other code), the most important thing, and not doing something to improve it under the guise of "getting websites fixed" is shirking the responsibility to provide the end user with the best possible experience.
You're right, of course. Off-the-cuff and all that.
In my defense, though, it should not, however, return unless everybody else has ceded time, too. So it might make your laptop angry, but other than that it isn't much of an issue. :)
I know. I was being a tongue-in-cheek asshole. :) An unpleasantly large number of computer scientists I know think you really can bash out every bug, though. The real world is not high on their list of priorities.
I hadn't read the comic. Very cool, though. Hopefully IE8 does the same thing (probably IE9, though).
Apple *had* an X server implementation when they started futzing with NeXT. They *fled* from using it as the core of their desktop, and for good reason.
And no, douchebag, I don't consider "server infrastructure" to be file browsers or window managers. Trying to write a performant graphics driver for X.org (which is the only X server that really matters, in a desktop context; Xming for Windows, as you alluded to, can't do most of what a modern desktop should be able to, though it's useful for a few tasks) requires you to rip out the lower third of the fucking server and wedge in custom code for it. Linux Hater Blog has an excellent explanation, for the people who don't know what they're talking about (that'd be you, champ): http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on-open-source.html
Managed code is not interpreted.
As for memory access violations: by far the most common segfault I see is dereferencing a null pointer, which I don't think you can really call a security weakness--just sloppy code.
I forgot about longjmp, my bad. That said, with longjmp you can come back from it, *sort of*, but as you said, you can't really guarantee program state, and so that's not really very useful.
Makes sense. I really don't know enough about Unix system internals, but this is very useful. Thanks! :)
Troll? Really? Because I said something against the beloved Firefox?
You can catch exceptions in c++ threads you know, and if you catch SEH exceptions you're catching the same exceptions as .NET apps do. So, its the platform that matters to get such stability, not the programming environment.
Go cause a segfault and catch the resulting exception, please. Oh, wait...
(No, signal handling doesn't count, if only because it can't be done on Windows, and if it doesn't work on Windows your web browser has a real tiny market share.)
Dunno about you, but I get random 2- to 5-second freezes in Firefox, and it crashes once a day or so on JavaScript.
Safari, I don't know, I won't pay extra to make my computer a style accessory.
Avast works well enough. 'Course, if you're a competent user, antivirus is largely unnecessary.
Firefox has done an absolute shit job. Right now, Firefox is, full-stop, the worst browser out there.
For that matter, IE8 already does what Chrome does. The browsers that don't are Konqueror, Firefox, Safari, and Opera (plus the assorted little browsers not worthy of mention. Get a clue.
IE8 will be performing well, and Firefox is going to have their balls in a vise, crushed by Chrome and IE8.
If you can't fix every bug--and you can't, so don't troll and say you can--graceful recovery is the next best thing. We live in the real world, not the computer scientist's world of "code can be perfect."
There are edge cases where HTML will crash IE (or used to), and I remember some cases that would kill Gecko.
JavaScript is an extremely gnarly language to actually implement (most prototype-based languages are), and it's very difficult to stomp on all the bugs. There are also cases where an infinite loop in the JavaScript can wedge the browser, which this alleviates.
Plugins are a major issue, and that's almost certainly the next thing to be put in its own process.
Keep in mind that yeah, there are bugs in browsers, and they should be stomped on--but you can't get them all, and graceful recovery is still great to have.
...whaaaaaaaat? Microsoft and Apple have moved *away* from X11 window systems. Because they completely fucking suck for desktop use. To get any reasonable desktop performance out of X, you have to replace about half of the server infrastructure (and anyone who thinks the way X.org is designed is *good* should please stop using computers).
People are not moving back to the processes-are-better view, either. In *this* case, processes have some benefits because they provide a greater amount of firewalling in case of crashes, because stability is the primary concern of a web browser these days (we've achieved good-enough performance). Threads are still better for the majority of computing tasks, if only due to shared address space (because IPC sucks to write and debug).
Get off the crack pipe.
It has nothing to do with Erlang and everything to do with basic design principles. Erlang did not invent what it preaches.
This really is important to remember. WinNT processes *are* slow, but not *that* slow anymore. (In the NT 3.5 days, on the other hand, a process could take tenths of a second to start up.)
Anything that's sensitive is almost certainly restricted to its own process. If it wasn't a share-nothing model, I'd be shocked.
Thread-locking isn't that hard, however...unless you were doing it in C or something equally abortionate.
WinNT processes are still slow, but a lot faster than they used to be. I don't have numbers offhand, but processes are not as expensive as they used to be (and you've got better hardware, too).
I agree with you; processes are only really a big win when you're dealing with a framework that can easily fly off the rails. Most native code falls into this category, because you generally can't even try to recover from a segfault/memory access violation, whereas Java/.NET give you the ability to at least attempt recovery. For managed code, though, threads or distributed objects (I prefer the former; they seem cleaner and more logical to me) are the way to go.
WinNT processes are considerably cheaper than they were when that was written in 2002, both because of more efficient code and faster hardware. Still slower than Unix, but the difference is not that great. (Unless you're running a really shitty antivirus, which would slow down process spawning.)
It's considerably easier to firewall a thread from taking the rest of the process down in .NET when using AppDomains, although it's still a difficult prospect and arguably more difficult to code and debug across AppDomains.