Last time there was a Slashdot article about the game, someone posted a link to someone who had fixed most of the bugs. Most of them were to do with the collision detection regions being subtly different from the drawn regions, so you'd step near a hole and fall in. With them fixed, it wasn't a bad game. If Atari had waited another week, they'd probably have had something good - just not in time for the Christmas buying season.
Lots of Flash games are orders of magnitude more complex than ET, in terms of story, game engine, and graphics, and are developed by one or two people. You have a lot more cycles to play with now, you can either burn them on development environments that make people more efficient, or on the game itself. AAA titles opt for the latter path, but they're not the only way that you can go. There are a load of systems where making something like Pac Man or Tetris is possible in a day or two for someone with no prior programming experience.
That varies a lot between people. Some people don't suffer from any physical symptoms of caffeine withdrawal at all. For a very small number, it's only slightly less bad than heroin withdrawal. Most people are somewhere on this spectrum.
Coffee in the USA, like the beer, only comes in extremes. It's either totally undrinkable, or really good. The difficulty is finding the good places, but fortunately the Internet is good at that. And with at leat 5 hours of jetlag whenever I visit, I always have an hour or two in the morning before anyone else is awake to find a decent coffee shop that I can be at just as it opens. So far the only place where I've not found a decent coffee place within easy walking distance of my hotel was Austin (I did find good coffee places, but nowhere was within easy walking distance of anywhere else in Austin), and in San Diego is was largely a coincidence that I happened to be near one. I think my favourite coffee shop was in Jacksonville, which had several kinds of decent coffee and a huge second-hand bookshop attached to the shop. The hotel 'proudly served Starbucks,' so it was worth the 15 minute stroll each way a couple of times a day to stock up.
Actually, Mexicans in the US are 3 times as likely to be rapists compared to their white counter part. Easily found in this document from the Department of Justice
That document neither talks about who commits the crimes, nor does it mention Mexicans. It does say that hispanic women are twice as likely to be victims of rape than white women, so perhaps you were confused. If we assume that every rape victim is raped by someone of the same ethnicity (dubious, but let's run with it), and that rape victims and rapists make up the same proportion of the population (also quite dubious: it's more likely that a rapist rapes multiple people) then that means that 99.88% of hispanics are not rapists, whereas 99.94% of whites are not rapists. Which makes the original claim fear-mongering nonsense.
Do I really need to go there? Fish in a barrel are envious about easy this one is. I mean, you brought this up. But, since you asked, in the last 3 days, 157 attacks in 22 countries killing 1747 people
In the same period, around 3,400 people died in road traffic accidents worldwide, around 128 of them in the USA. Oh, and around 14 murders are committed every 3 days by white men in the USA. If you think that your chance of being blown up by a muslim is statistically significant, then you're an idiot.
Fingerprints work fine for authentication if there is a human checking that it's actually your finger going on the reader (and not, for example, a jelly baby) and if the value of the thing that it's protecting is low enough that it's not worth printing custom finger coverings that mimic someone else's print. They're most useful for deterring casual attempts. Using them to unlock a phone means that some random stranger who picks up your phone can't instantly unlock it. An adversary that wants to invest time and effort can do so, but that's not the threat model that it's intended for.
Too many people left things behind when it happened at once. So now the card doesn't come out until AFTER you take the money.
Are you sure? That's a regression if it's really the case. The normal design is to not release the money until after the user has taken their card because the user's attention is on the goal (getting the money) and once that's achieved they are very likely to forget anything else associated with the task (including getting the card). In the UK, instances of people leaving cards in machines dropped hugely in the '80s when they switched the order from release-money-then-card to release-card-then-money.
But that's still no excuse to not start counting the money until after the user has decided if they want a receipt and the card has been taken. The machine doesn't have to release the money (open the cash slot) until after the card is gone, but it could still have the money ready. There's already an error recovery path if the user forgets to take the money (it drops into a bin and the transaction is cancelled - this was exploited last year by some thieves who asked for large amounts of money and then took the notes from the middle of the pile, triggering the machine to take back the ones it still could detect were there and refund the withdrawal).
The problem with the POSIX subsystem on NT is that it works in roughly the same way as syscall emulation on *NIX systems. On FreeBSD, for example, you can run a Linux binary and it will have a Linux syscall table instead of a FreeBSD one. Unfortunately, it then can't make FreeBSD syscalls. That's not usually a problem, because if you're actually porting code from Linux to FreeBSD and want to use FreeBSD-specific features then you probably recompile it. With NT, you have the same issue, but there it actually matters: you can either issue POSIX system calls or Win32 ones, but not both from the same program. If you want to use the GUI, then you have to use the Win32 subsystem. If you want to also use POSIX APIs then you had to split your program into two parts and communicate via some IPC channel. This made it largely useless and is why MinGW, Cygwin, and SFU all use the Win32 subsystem and map library calls to Win32 syscalls.
It's a bit more subtle than that, I suspect. If you want to provide something as evidence in court, then you must be able to demonstrate that correct forensic procedures have been followed. If you hack into a device, then it's quite difficult to show beyond reasonable doubt that you did so in a way that guarantees that the content of the data was not modified (accidentally or maliciously). It's been a while since I was involved with anything in this area, but back then they had special IDE cables with the write wires disconnected, for example so that you could plug the forensics computer into the drive and be absolutely certain that you weren't modifying it while imaging it.
The problem with a lot of the overreaching terrorism legislation is that it destroys this evidence chain. Anyone who is under investigation may have their computer hacked by the police / intelligence agencies, and therefore being under suspicion of such a crime gives a good defence that anything found on their computer may have been planted or tampered with by the same authorities. Any politician who campaigns on a platform of law and order should oppose them for this reason.
No, I use tabs for indentation. I use spaces for alignment. Every line starts with n tabs, where n is the current indent level. If I need to line things up, then I will use spaces after the tabs.
Deregistering something that was not registered properly in the first place is often a very dangerous, and incorrect, thing to be doing!
It is a bug, but it's not actually dangerous. The unregister function contains checks that the thing that it's unregistering is registered and silently does nothing if it isn't. If this weren't the case, lots of people would have seen odd behaviour.
You can set a prettyprinter to support just about any formatting standard you prefer these deays. (How many spaces in a tab, braces on end of line or separate lines and so on)
I've still not found one that supports my coding style, which uses one tab for each indent level and spaces for alignment (so you can adjust the tab width in the editor and still have correctly formatted code, whatever value you pick). Actually, that's not quite true: one of my students wrote one that did just that (and use the TeX line-breaking algorithm with different penalties for different syntactic features), but it never progressed beyond a student project and then some guys at Google came along and wrote something much less good as clang-format.
This is one of my pet peeves too. It's also something that I really like about Smalltalk: there is no operator precedence, operators are evaluated left to right and if you want something other than left-to-right order, then you must add parentheses. This means that you never spend time in Smalltalk code wondering if the developer got the precedence wrong.
Coverity, along with most static analysers, has problems with false positives. I spent an afternoon wading through the coverity reports in my own code in FreeBSD libc. I found one possible bug (I think that the code was unreachable, but I may have missed something in one of the callers), all of the rest were false positives. Some were trivial to discount - they were simple artefacts of the fact that Coverity works one compilation unit at a time and a cursory glance at the other compilation unit showed that it was not a problem. The others required a bit more digging. In particular, Coverity seemed to be really confused by some reference counting functions.
I've only had time to glance over the PVS results, but they seemed to be more useful.
Coverity is free for open source projects, you can sign up from their web page and they'll scan your repo (and email out reports, or let you view them from the web interface). It's only expensive if you want to run it on your own systems or for code that isn't public.
Tape is a pretty good example, but it's not quite the same. Both tape and hard drives have the attribute that they need a huge R&D investment to keep advancing and that has to be recouped. Tape has slowly moved to the high end with an ever diminishing customer base, who are willing to pay the premium because tape has good archival properties, but at the same time that premium will keep going up. Each new generation of tape (or disk) costs more to research than the previous one and as fewer people are paying that cost it translates to sharp per-unit price increases for each generation. The price of an entry level tape drive has gone up by about an order of magnitude in the last decade. Eventually, the cost-benefit ratio stops being in the right direction, more customers migrate away, the per-unit price goes up too much for the next group and you're in a death spiral. Most of the customers of tape now have such long upgrade cycles that they'll still be buying the same stuff in a decade, but that doesn't help much with financing the next iteration.
Disk is different though. Currently, the only reason to prefer spinning rust to SSDs is price per GB. Disks are less reliable, slower (a bit slower for linear transfer, much slower for random access), use more power, are physically bigger, are no more useful for long-term offline archiving. If you made SSDs for the same price per GB as disks today, then there wouldn't be enough people buying spinning rust to make it worthwhile producing new disks.
So limit the amount that I can download per month. I am renting DVDs and the same argument applies: I could rip every DVD that I rent and amass a big library. I don't, because why would I? I pay the subscription for two reasons:
Access to new content. I don't just want to watch films / TV shows from before a certain snapshot point, I want to keep having access to new material.
So that I don't have to keep a huge library of things that I'll probably only watch once or maybe twice.
These are both good incentives for me to keep paying a subscription and not to download everything. Even without caps, the amount of disk space that I'd need to download everything that I might possibly want to watch for even a year would be huge (and it would be fairly easy to spot people who signed up for a month, downloaded a huge amount, cancelled their account, then repeated the process a year later).
Neither of these requirements would be satisfied by downloading things. I don't want to have to curate a collection of movies and TV shows, I want to pay someone else to do that for me and to keep adding new things that I might want to watch to it. And I want the economic incentives for the supplier to be to keep creating new things that I want to watch (and, actually, the studios probably want the economic incentives for companies like Amazon and Netflix to be for them to have to keep adding things to their library). And, most importantly, if I were happy to pirate then I wouldn't bother signing up for their service anyway. I sign up because I want to give them money in exchange for something of value to me, in the hope that this will cause more stuff that I like to be created. I'm pretty sure that anything that I want to watch is available illegally already. The existence of DRM wouldn't stop me from getting it from The Pirate Bay, or whatever the kids use these days, but it probably would stop me from using it legitimately. And that means that it also stops me from giving them money.
What consumers really want is a service like Amazon Prime or Netflix where a single monthly fee provides on demand access to an entire library or catalog of content that can be watched anytime from any device
And that includes downloads, not just streaming. I really want to have access to rented movies when I'm on a long train or plane journey, but if I do have Internet on either of those it is going to be either unreliable or expensive. I want to be able to load the stuff onto my device first. And please don't cripple it with DRM, because I know that DRM means 'it works now, but will stop working when you actually want to watch it'. If I wanted to pirate it, I'd have done so already - high quality rips of all of your movies are already available illegally, please give me an equally good (or, ideally, more convenient) product that I can pay for.
I still rent DVDs, because that's the only format that I can guarantee that I can play. I'd love to see Hollywood as a whole hit with a carbon tax for every physical copy that's made and distributed because of their insistence on obnoxious DRM on everything else.
The worst thing is that DRM isn't even in the studios best interests. All it does is lock people into the platform that controls the DRM. The music labels learned this when Apple ended up owning the distribution channel as a result of their insistence that the iTunes Music Store used DRM.
No, but that's not really the point (actually, all of the others have added additional security features, but they all had sandboxing last year). The point is that Firefox does not implement the core mechanisms for security that the others all had last year (and, mostly, the year before and the year before that too). This makes is uninteresting as a target.
This is a reliability measure, not a security measure. The process that plugins run with is not sandboxed and runs with ambient authority. It can read every file in the user's home directory and can open arbitrary network connections. If Flash crashes, then it won't crash Firefox (which is a good thing), but if Flash is compromised then it's exactly the same as if Firefox were compromised. In contrast, if Flash is compromised in Safari or Chrome, the attacker has access to a process running with very restricted privileges and an IPC channel to the browser. To do anything useful, the attacker must use the IPC channel to compromise the sandboxed renderer process, then do the same thing again (though likely with a different vulnerability) to compromise the main browser process (the one that runs with ambient authority). You need, at a minimum, three exploits: one in Flash and two in the browser, to get from a malicious Flash app to a user-level compromise in Chrome or Safari. With Firefox, you need just the first one to do the same amount of damage.
Now look at the entitlements for that process. It runs without any sandboxing. A crash in the plugin won't crash the browser, but a compromise of that plugin will give enough privileges to attach a debugger to the main process (on OS X the system will prompt for this, because it looks suspicious, but it can still open arbitrary network connections and read every file in your home directory). Reliability and security often have similar mechanisms, but don't confuse one for the other.
The former. All modern browsers except Firefox have decomposed their browser into multiple processes, so that a compromise from one site will only gain control over an unprivileged (i.e. isolated from other stuff the user cares about) process. They also run plugins in separate processes and have fairly narrow communication paths between them. Firefox is still a massive monolithic process, including all add-ons, plugins, and so on.
This basically means that you just need one arbitrary code execution vulnerability in Firefox and it's game over. In contrast, if you have the same in Chrome, Edge, or Safari, then it's just the first step - you now have an environment where you can run arbitrary exploit code, but you can't make (most) system calls and you have to find another exploit to escape from the sandbox. Typical Chrome compromises are the result of chaining half a dozen vulnerabilities together.
Slashdot Mirror
Last time there was a Slashdot article about the game, someone posted a link to someone who had fixed most of the bugs. Most of them were to do with the collision detection regions being subtly different from the drawn regions, so you'd step near a hole and fall in. With them fixed, it wasn't a bad game. If Atari had waited another week, they'd probably have had something good - just not in time for the Christmas buying season.
Lots of Flash games are orders of magnitude more complex than ET, in terms of story, game engine, and graphics, and are developed by one or two people. You have a lot more cycles to play with now, you can either burn them on development environments that make people more efficient, or on the game itself. AAA titles opt for the latter path, but they're not the only way that you can go. There are a load of systems where making something like Pac Man or Tetris is possible in a day or two for someone with no prior programming experience.
The problem with your argument is right now I can have both
Yes, but it's really hard to avoid spilling the coffee.
That varies a lot between people. Some people don't suffer from any physical symptoms of caffeine withdrawal at all. For a very small number, it's only slightly less bad than heroin withdrawal. Most people are somewhere on this spectrum.
Coffee in the USA, like the beer, only comes in extremes. It's either totally undrinkable, or really good. The difficulty is finding the good places, but fortunately the Internet is good at that. And with at leat 5 hours of jetlag whenever I visit, I always have an hour or two in the morning before anyone else is awake to find a decent coffee shop that I can be at just as it opens. So far the only place where I've not found a decent coffee place within easy walking distance of my hotel was Austin (I did find good coffee places, but nowhere was within easy walking distance of anywhere else in Austin), and in San Diego is was largely a coincidence that I happened to be near one. I think my favourite coffee shop was in Jacksonville, which had several kinds of decent coffee and a huge second-hand bookshop attached to the shop. The hotel 'proudly served Starbucks,' so it was worth the 15 minute stroll each way a couple of times a day to stock up.
Actually, Mexicans in the US are 3 times as likely to be rapists compared to their white counter part. Easily found in this document from the Department of Justice
That document neither talks about who commits the crimes, nor does it mention Mexicans. It does say that hispanic women are twice as likely to be victims of rape than white women, so perhaps you were confused. If we assume that every rape victim is raped by someone of the same ethnicity (dubious, but let's run with it), and that rape victims and rapists make up the same proportion of the population (also quite dubious: it's more likely that a rapist rapes multiple people) then that means that 99.88% of hispanics are not rapists, whereas 99.94% of whites are not rapists. Which makes the original claim fear-mongering nonsense.
Do I really need to go there? Fish in a barrel are envious about easy this one is. I mean, you brought this up. But, since you asked, in the last 3 days, 157 attacks in 22 countries killing 1747 people
In the same period, around 3,400 people died in road traffic accidents worldwide, around 128 of them in the USA. Oh, and around 14 murders are committed every 3 days by white men in the USA. If you think that your chance of being blown up by a muslim is statistically significant, then you're an idiot.
Fingerprints work fine for authentication if there is a human checking that it's actually your finger going on the reader (and not, for example, a jelly baby) and if the value of the thing that it's protecting is low enough that it's not worth printing custom finger coverings that mimic someone else's print. They're most useful for deterring casual attempts. Using them to unlock a phone means that some random stranger who picks up your phone can't instantly unlock it. An adversary that wants to invest time and effort can do so, but that's not the threat model that it's intended for.
Too many people left things behind when it happened at once. So now the card doesn't come out until AFTER you take the money.
Are you sure? That's a regression if it's really the case. The normal design is to not release the money until after the user has taken their card because the user's attention is on the goal (getting the money) and once that's achieved they are very likely to forget anything else associated with the task (including getting the card). In the UK, instances of people leaving cards in machines dropped hugely in the '80s when they switched the order from release-money-then-card to release-card-then-money.
But that's still no excuse to not start counting the money until after the user has decided if they want a receipt and the card has been taken. The machine doesn't have to release the money (open the cash slot) until after the card is gone, but it could still have the money ready. There's already an error recovery path if the user forgets to take the money (it drops into a bin and the transaction is cancelled - this was exploited last year by some thieves who asked for large amounts of money and then took the notes from the middle of the pile, triggering the machine to take back the ones it still could detect were there and refund the withdrawal).
The problem with the POSIX subsystem on NT is that it works in roughly the same way as syscall emulation on *NIX systems. On FreeBSD, for example, you can run a Linux binary and it will have a Linux syscall table instead of a FreeBSD one. Unfortunately, it then can't make FreeBSD syscalls. That's not usually a problem, because if you're actually porting code from Linux to FreeBSD and want to use FreeBSD-specific features then you probably recompile it. With NT, you have the same issue, but there it actually matters: you can either issue POSIX system calls or Win32 ones, but not both from the same program. If you want to use the GUI, then you have to use the Win32 subsystem. If you want to also use POSIX APIs then you had to split your program into two parts and communicate via some IPC channel. This made it largely useless and is why MinGW, Cygwin, and SFU all use the Win32 subsystem and map library calls to Win32 syscalls.
It's a bit more subtle than that, I suspect. If you want to provide something as evidence in court, then you must be able to demonstrate that correct forensic procedures have been followed. If you hack into a device, then it's quite difficult to show beyond reasonable doubt that you did so in a way that guarantees that the content of the data was not modified (accidentally or maliciously). It's been a while since I was involved with anything in this area, but back then they had special IDE cables with the write wires disconnected, for example so that you could plug the forensics computer into the drive and be absolutely certain that you weren't modifying it while imaging it.
The problem with a lot of the overreaching terrorism legislation is that it destroys this evidence chain. Anyone who is under investigation may have their computer hacked by the police / intelligence agencies, and therefore being under suspicion of such a crime gives a good defence that anything found on their computer may have been planted or tampered with by the same authorities. Any politician who campaigns on a platform of law and order should oppose them for this reason.
No, I use tabs for indentation. I use spaces for alignment. Every line starts with n tabs, where n is the current indent level. If I need to line things up, then I will use spaces after the tabs.
Deregistering something that was not registered properly in the first place is often a very dangerous, and incorrect, thing to be doing!
It is a bug, but it's not actually dangerous. The unregister function contains checks that the thing that it's unregistering is registered and silently does nothing if it isn't. If this weren't the case, lots of people would have seen odd behaviour.
You can set a prettyprinter to support just about any formatting standard you prefer these deays. (How many spaces in a tab, braces on end of line or separate lines and so on)
I've still not found one that supports my coding style, which uses one tab for each indent level and spaces for alignment (so you can adjust the tab width in the editor and still have correctly formatted code, whatever value you pick). Actually, that's not quite true: one of my students wrote one that did just that (and use the TeX line-breaking algorithm with different penalties for different syntactic features), but it never progressed beyond a student project and then some guys at Google came along and wrote something much less good as clang-format.
This is one of my pet peeves too. It's also something that I really like about Smalltalk: there is no operator precedence, operators are evaluated left to right and if you want something other than left-to-right order, then you must add parentheses. This means that you never spend time in Smalltalk code wondering if the developer got the precedence wrong.
Coverity, along with most static analysers, has problems with false positives. I spent an afternoon wading through the coverity reports in my own code in FreeBSD libc. I found one possible bug (I think that the code was unreachable, but I may have missed something in one of the callers), all of the rest were false positives. Some were trivial to discount - they were simple artefacts of the fact that Coverity works one compilation unit at a time and a cursory glance at the other compilation unit showed that it was not a problem. The others required a bit more digging. In particular, Coverity seemed to be really confused by some reference counting functions.
I've only had time to glance over the PVS results, but they seemed to be more useful.
Coverity is free for open source projects, you can sign up from their web page and they'll scan your repo (and email out reports, or let you view them from the web interface). It's only expensive if you want to run it on your own systems or for code that isn't public.
Tape is a pretty good example, but it's not quite the same. Both tape and hard drives have the attribute that they need a huge R&D investment to keep advancing and that has to be recouped. Tape has slowly moved to the high end with an ever diminishing customer base, who are willing to pay the premium because tape has good archival properties, but at the same time that premium will keep going up. Each new generation of tape (or disk) costs more to research than the previous one and as fewer people are paying that cost it translates to sharp per-unit price increases for each generation. The price of an entry level tape drive has gone up by about an order of magnitude in the last decade. Eventually, the cost-benefit ratio stops being in the right direction, more customers migrate away, the per-unit price goes up too much for the next group and you're in a death spiral. Most of the customers of tape now have such long upgrade cycles that they'll still be buying the same stuff in a decade, but that doesn't help much with financing the next iteration.
Disk is different though. Currently, the only reason to prefer spinning rust to SSDs is price per GB. Disks are less reliable, slower (a bit slower for linear transfer, much slower for random access), use more power, are physically bigger, are no more useful for long-term offline archiving. If you made SSDs for the same price per GB as disks today, then there wouldn't be enough people buying spinning rust to make it worthwhile producing new disks.
I have two words that should explain why this is not such a great idea: IBM Deathstar.
Twitter might end up looking like nothing more than a place where whiners go to whine
I doubt it. Even Twitter's management isn't stupid enough to position themselves as a direct competitor to Facebook.
So limit the amount that I can download per month. I am renting DVDs and the same argument applies: I could rip every DVD that I rent and amass a big library. I don't, because why would I? I pay the subscription for two reasons:
These are both good incentives for me to keep paying a subscription and not to download everything. Even without caps, the amount of disk space that I'd need to download everything that I might possibly want to watch for even a year would be huge (and it would be fairly easy to spot people who signed up for a month, downloaded a huge amount, cancelled their account, then repeated the process a year later).
Neither of these requirements would be satisfied by downloading things. I don't want to have to curate a collection of movies and TV shows, I want to pay someone else to do that for me and to keep adding new things that I might want to watch to it. And I want the economic incentives for the supplier to be to keep creating new things that I want to watch (and, actually, the studios probably want the economic incentives for companies like Amazon and Netflix to be for them to have to keep adding things to their library). And, most importantly, if I were happy to pirate then I wouldn't bother signing up for their service anyway. I sign up because I want to give them money in exchange for something of value to me, in the hope that this will cause more stuff that I like to be created. I'm pretty sure that anything that I want to watch is available illegally already. The existence of DRM wouldn't stop me from getting it from The Pirate Bay, or whatever the kids use these days, but it probably would stop me from using it legitimately. And that means that it also stops me from giving them money.
What consumers really want is a service like Amazon Prime or Netflix where a single monthly fee provides on demand access to an entire library or catalog of content that can be watched anytime from any device
And that includes downloads, not just streaming. I really want to have access to rented movies when I'm on a long train or plane journey, but if I do have Internet on either of those it is going to be either unreliable or expensive. I want to be able to load the stuff onto my device first. And please don't cripple it with DRM, because I know that DRM means 'it works now, but will stop working when you actually want to watch it'. If I wanted to pirate it, I'd have done so already - high quality rips of all of your movies are already available illegally, please give me an equally good (or, ideally, more convenient) product that I can pay for.
I still rent DVDs, because that's the only format that I can guarantee that I can play. I'd love to see Hollywood as a whole hit with a carbon tax for every physical copy that's made and distributed because of their insistence on obnoxious DRM on everything else.
The worst thing is that DRM isn't even in the studios best interests. All it does is lock people into the platform that controls the DRM. The music labels learned this when Apple ended up owning the distribution channel as a result of their insistence that the iTunes Music Store used DRM.
No, but that's not really the point (actually, all of the others have added additional security features, but they all had sandboxing last year). The point is that Firefox does not implement the core mechanisms for security that the others all had last year (and, mostly, the year before and the year before that too). This makes is uninteresting as a target.
This is a reliability measure, not a security measure. The process that plugins run with is not sandboxed and runs with ambient authority. It can read every file in the user's home directory and can open arbitrary network connections. If Flash crashes, then it won't crash Firefox (which is a good thing), but if Flash is compromised then it's exactly the same as if Firefox were compromised. In contrast, if Flash is compromised in Safari or Chrome, the attacker has access to a process running with very restricted privileges and an IPC channel to the browser. To do anything useful, the attacker must use the IPC channel to compromise the sandboxed renderer process, then do the same thing again (though likely with a different vulnerability) to compromise the main browser process (the one that runs with ambient authority). You need, at a minimum, three exploits: one in Flash and two in the browser, to get from a malicious Flash app to a user-level compromise in Chrome or Safari. With Firefox, you need just the first one to do the same amount of damage.
Now look at the entitlements for that process. It runs without any sandboxing. A crash in the plugin won't crash the browser, but a compromise of that plugin will give enough privileges to attach a debugger to the main process (on OS X the system will prompt for this, because it looks suspicious, but it can still open arbitrary network connections and read every file in your home directory). Reliability and security often have similar mechanisms, but don't confuse one for the other.
This basically means that you just need one arbitrary code execution vulnerability in Firefox and it's game over. In contrast, if you have the same in Chrome, Edge, or Safari, then it's just the first step - you now have an environment where you can run arbitrary exploit code, but you can't make (most) system calls and you have to find another exploit to escape from the sandbox. Typical Chrome compromises are the result of chaining half a dozen vulnerabilities together.