As far as I know, Coreboot (open source bios) comes close
I was speaking of hardware, not software. If you are rewriting the BIOS you can of course identify the shortest sequence of instructions to get the CPU into 64 bit mode and always start with that exact sequence of instructions. You can probably leave that initial sequence of instructions unchanged for years as you go about developing new versions of the 64 bit code. I don't think vendors consider it important to get rid of the 16 bit or 32 bit modes. Allegedly the silicon which could be saved is negligible, and it doesn't require much design work since it is just the same thing as previous versions (except getting smaller as manufacturing processes improve). I think the real blockers for getting rid of it is the APIs between main BIOS, extension card BIOSes (VGA, PXE, and harddisk), and bootloader. Those APIs are for the most part 16 bits with a few pieces of 32 bits.
Your link isn't working for me. I get a connection reset from that webserver.
Going further, I wonder if it is possible to rip the 32-bit parts completely away from the silicon at some point?
Do you want that to happen before or after ripping out the 16-bit parts? Even the latest 64-bit CPUs boot up in 16-bit mode. As far as I recall you still need 32-bit mode because there isn't support for switching directly from 16-bit mode to 64-bit mode.
Are there any AMD64 (or compatible) CPUs, which can be powered on directly in 64-bit mode? Supporting that would be the first step towards getting 16-bit and 32-bit modes out of the CPUs.
Do you know how your system would work? The big traders would hold their trades until the last microsecond of the time block. This would happen no matter which deadline you use.
If the system was done like I suggested waiting until just before the deadline would give you a disadvantage. The longer you wait the higher the risk of missing the deadline. Putting in your bids early don't harm, they only gets published after the deadline. Additionally the system could allow you to modify your bids until the deadline if you should wish to do so, but there won't be any new information available within the system during that period, so it is unlikely to be of much benefit to be able to modify bids like that.
The big investment banks have information about the trades that go through them. They know the way the wind is blowing.
So, some people may not be accessing the market directly, but rather be trading by proxy (or whatever the technical term is for this sort of trading). Shouldn't change anything if the company you choose to proxy for you is trustworthy. But if you do trades through a company without any agreement about confidentiality, and if that company even utilizes information about your trades (which is not yet public) to optimize their own bids, then of course they get an advantage. That may not fall under the definition of insider trading, but it does sound like the same ballpark to me.
Nope, won't work. Laws of physics must be observed. Take your 10ns proposal and subtract the communication latency to find out how much time is left for computations. Turns out that the communication latency alone is going to be 3-8 orders of magnitude higher.
What you need to do to make the model workable is to consider the best case and worst case latency for the traders and use that to compute the best and worst case time available for computation. And it is the time available for computation, which must not differ by too many percents. Realistic numbers would be communication latencies between 100usec and 300msec. The best case latency is actually negligible, assuming it is zero will not affect the outcome of the calculations much.
Assuming 500msec per round with the above numbers the time left for computation would vary between 200msec and 500msec. That's 150% more time for the best case than the worst case, meaning traders with worst case latency must acquire hardware which is 150% faster to remain competitive. Increase the round duration to 2sec and the numbers now become 1700msec and 2000msec, only 18% difference.
Couldn't the calculation of those bits of data which rely on outstanding orders simply be done less frequently? I'm assuming it isn't truly realtime, so why not just make it every second instead? Wouldn't that achieve roughly the same result of removing the value of that latency?
The problem to be solved is this one. Trader A places, modifies, or cancels a bid. Trader B and trader C see the information about A's bid being published. In response to that change, both B and C want to place, modify, or cancel a bid of their own. But whether the change made by B or the change made by C gets to the exchange first can affect the trades happening.
This means whoever can get information about changes in bids and in response to that modify their own bids with the lowest latency has an advantage. I cannot see how that can be solved without introducing rounds.
In the above example it could be that B and C both want to trade with A and whoever gets there first gets to trade with A. But the updates that B and C want to make don't have to be about trades with A. It may just as well be that B and C could trade with each other or with a fourth party.
Read what I wrote again. There is no such thing as turns. In fact the word turn was not even used until you brought it up. There are rounds and each round everybody gets to place bids. Until the deadline of a round you get to place or modify your bids, but none of the bids are published until after the deadline. After the deadline all bids are published and trades are executed according to the bids.
In the simplest model bids are valid for a single round only, and if they could not be matched in that round they are automatically cancelled again. You have to keep placing the bid each round if you still want to be trading at the price of your previous bid. If you leave for lunch and don't have a computer refresh your bids while at lunch, you simply won't be trading for that duration.
In a slightly more complicated model bids are valid until a specified expiration time. Such bids are valid for multiple rounds, and if you want to cancel the bid before expiration, you have to explicitly cancel it. In each round a time stamp of the next deadline will be published, any active bids expiring after that deadline are still valid in the next round, unless cancelled before the deadline.
In principle the two models are the same. The expiration time is just an optimization. Without it traders would need a computer to republish their bid every round, which would consume some networking resources. But the more complicated model could trivially be simulated with the simpler model. If traders are going to update their prices each round, the benefit of bids valid for multiple rounds disappears.
The point of the model is that once information is published, there is a number of seconds until the next deadline, during that period everybody have the same public information to work with. There is no rush to submit bids, because any bid before the deadline is equally valid. A few microseconds more or less for computation isn't important when you have more than five seconds to complete the computation you need in order to place a bid.
Effectively each round is a double auction with secret bids.
This! Best idea I have seen so far - is it yours or has it been researched in more detail and been published somewhere?
I came up with the idea, but I think it is simple enough that others could easily have come up with it independently before or after me. So there may be detailed research of the idea, which I just don't know about.
Always good to be reassured that the market reflects the intrinsic value of the companies instead of behaving as a high-tech casino.
There is a reason why people who need numbers that are provably random, compute a hash value of stock indexes. Wall Street has build the world's most sophisticated (P)RNG.
All these stories about traders needing ultralow latencies is a symptom of a fundamentally broken system. There are places where low latencies add value, stock trading is not one of them. Reduce the latency of everybody involved in the stock market, and nobody will have gained anything (except from the tech companies selling the technology being used).
The system should be modified to be round based rather than real-time. 10 seconds per round is long enough that all traders can have equal access regardless of how far they are from the stock exchange, and it is short enough that it won't be a hindrance to long-term investors. A round could spend a couple of seconds executing the trades, then publish the results, add another couple of seconds for communication, and traders will still have six seconds for calculations before the deadline for the next trading round.
With such a round based system you will change from competing on having the shortest distance to competing on having the best algorithms. Nobody will get an unfair advantage by having a shorter distance. Even if somebody does have one second more for calculations due to shorter distance, somebody further away can make up for that by a small increase in processing power. This is different from the latency based game, where no amount of processing power can make up for the additional latency.
The Latitude 13 I bought two years ago with Ubuntu preinstalled was significantly cheaper than the same machine with Windows. I don't remember the exact price difference, but I am pretty sure it was somewhere between 50 and 250$. It isn't the most durable hardware I have owned, and their customer support isn't stellar. But being able to buy a laptop with Linux preinstalled cheaper than the same hardware with Windows is worth something to me. I don't mind having to buy more expensive hardware to get something, which works with Linux. But that doesn't mean I want to pay more for the same hardware. Neither do I want to take part in funding all the things that Microsoft stands for. I may consider buying such an ultrabook once the price comes down.
Parent post is correct. Pages are not evaluated by people, but rather by an algorithm. And search results are not produced by people, but rather by an algorithm. But the algorithms don't magically appear. Those algorithms are written by people. But even smart people with good intentions cannot know if an algorithm is going to produce a good result or not. And this is where the human raters come into the picture. Their job really is to evaluate the variations of the algorithms introduced by the developers, to ensure that improvements to the algorithm make it through and other changes do not.
I'm not sure how a self updating program that the user installs in $HOME compromises security.
That is not exactly the situation I was referring to.
Any program a user installs for himself under his home directory should of course not be a thread to the overall security of the system. If it does, it is not the program that is to blame, but rather the OS. So it really should only put that user at risk. Some people are so paranoid about security, that they do not want non-administrator users to be able to write and run an executable. Any file system those users have write access to, should be mounted noexec. I think that is going too far, but a program should still be designed such that it can work in such an environment.
Even if it only threatens the user, who installed the program, there is however still some security issues. First of all you don't have as strong guarantees about timely updates. If the program is updated through a package manager, it will notice an update is available. If the program updates itself, it will only notice next time you start the program. So it takes longer time before you get the update. And that may be the time it takes for an exploit to be developed, which could hit the program in the time window from you start it until it realizes, that it needs updating.
However the main issue with this approach isn't the security threat, but rather that a program isn't supposed to contain code unrelated to the purpose of the program. If the purpose of the program isn't to install software updates, then it shouldn't contain code to install software updates. If every single program you install had its own code for installing software updates, you'd have loads of duplicated functionality, and with that many pieces of code intended to do the same thing, some of them are bound to be broken in some way.
The actual situation I was referring to was that of a program installed by root through a package file. That package file could be an rpm or deb file, which you downloaded from a website, or it could be found through a repository. When such a program is run by another user, it should not have any permissions to write to the package's files.
I have an AT&T SGS II. It's running Cyanogenmod 10 and is unlocked.
When I said "unlike other phones", it was not to be read as "unlike all other phones". Rather it was to be read as "unlike some other phones" or "unlike most other phones". I was merely pondering on the fact that it was considered newsworthy, that you can own a phone, which you have bought.
You can own a Nexus phone, you just have to buy it. Unlike other phones, which are still owned by the vendor even after they have been bought by a consumer.
The hacks needed in order to pull that off will put the security of the entire system at risk. This is something Linux distributions should fix. But the proper fix is not what those people behind self updating packages may have in mind. It needs to be fixed by not putting the same level of trust in every repository. The fix would break all the self-updating packages by removing their privileges to update themselves.
Only packages from repositories trusted by root, should be able to install files in directories from where they can be executed by root. Packages from other repositories shouldn't be able to install files in those directories, neither should they have any ability to install device inodes or files that are suid or sgid to root. And an update for a package mustn't come from a less trusted repository. Finally when a user logs in, the path should be set up to include only directories from those repositories that user trusts.
To give software distributors the right incentives, there should be tools making it easier to build packages and repositories. If it was easier to do things the right way and harder to do self-updating hacks, then we may see more software distributors do it right.
Remember most of those software distributors come with experience from Windows, where there is no right way of managing software. They take what they have learned on Windows and try to apply it to Linux. Though every Linux distribution actually has a right way of managing software, even a small learning curve may put off distributors and make them choose the hacks instead.
Now I see how instant runoff could have shortcomings compared to other methods. There is however a long list of criteria for elections. Each of those criteria in itself sounds very sensible and something you could reasonably require a voting system to satisfy. Unfortunately they are incompatible, and you cannot have a system satisfy all of them.
I am wondering, if there was to be an election to chose a voting system, how that would turn out. And should such an election chose a preference of the voting systems or a preference of the criteria characterizing good voting systems?
It is complicated, but that complexity shouldn't stand in the way of replacing a clearly inferior system with a better system.
The electoral college and "winner-takes-all" mechanic is what turns it into a two-party system.
That too. But eliminating that wouldn't solve the two-party problem. You'd need to remove the incentives turning it into a two-party party system from both the levels of the election. The two levels in the election is a left-over from a time where communication was a technical challenge. Today we have technology that overcomes all those hurdles. A direct vote with preferential voting would make the system much more democratic, and eliminate the two-party effect. Alas the people in a position to change it are exactly the people, who benefit from the two-party effect.
Instant run-off is the pretty much the single-winner preference voting system that does the least to mitigate the problems with first-past-the-post elections that preference voting systems are usually offered to resolve.
The problems mentioned in the Wikipedia article on first-past-the-post voting are solved by instant run-off. The most prominent problem is that first-past-the-post effectively is run-off voting with the first round of voting being done by the media rather than the voters. With run-off or instant run-off that problem is solved by taking that power away from the media and giving it to the voters. So I don't know which other problems you are referring to. Could you describe the problem, and how it could be solved?
When people don't do the latter, you get the situation we have in the U.S. - where people who would really prefer the Libertarian candidate end up voting for a Democrat or Republican. Because everyone "knows" the Libertarian candidate could never win. (There are other ways to combat this, e.g. instant run-off voting, but that's a different discussion.)
What you describe is the reason why such systems turn into two-party systems. I don't think that is a very democratic system. There are different variations of voting systems that can improve that situation. The instant runoff, which you mentioned, is probably the best. I knew the system already (it is quite simple, any nerd would be able to come up with that design), but I didn't know the name of the system, so thanks for mentioning it.
I'd assume the countries, which have not yet banned those magnets, make up a sufficiently large market for at least one or two manufacturers of them to still be in business. I can't say whether it would then be legal for individuals to import some for their own entertainment.
When have any of those things you mentioned other than nuclear war ever come close to happening outside of a sci-fi novel?
It does not only happen in sci-fi novels, it also happens in sci-fi movies. Somehow because it happens in sci-fi, lots of people think it is likely to happen in the real world as well. Why are people so easy to manipulate, that just because you make fiction about something, lots of people will actually perceive it as a real threat?
There are real threats to mankind, but I don't think mankind is a threat to life in general. We are a threat to specific species, including ourselves. But though we may cause many species to go extinct, I don't believe we could wipe out life on Earth. But is earthlife going to survive when the Sun boils away our oceans millions of years from now? If mankind goes extinct, will there be enough time for a new civilisation to develop the capability to travel through space in the Earth's lifetime?
Slashdot Mirror
I was speaking of hardware, not software. If you are rewriting the BIOS you can of course identify the shortest sequence of instructions to get the CPU into 64 bit mode and always start with that exact sequence of instructions. You can probably leave that initial sequence of instructions unchanged for years as you go about developing new versions of the 64 bit code. I don't think vendors consider it important to get rid of the 16 bit or 32 bit modes. Allegedly the silicon which could be saved is negligible, and it doesn't require much design work since it is just the same thing as previous versions (except getting smaller as manufacturing processes improve). I think the real blockers for getting rid of it is the APIs between main BIOS, extension card BIOSes (VGA, PXE, and harddisk), and bootloader. Those APIs are for the most part 16 bits with a few pieces of 32 bits.
Your link isn't working for me. I get a connection reset from that webserver.
Do you want that to happen before or after ripping out the 16-bit parts? Even the latest 64-bit CPUs boot up in 16-bit mode. As far as I recall you still need 32-bit mode because there isn't support for switching directly from 16-bit mode to 64-bit mode.
Are there any AMD64 (or compatible) CPUs, which can be powered on directly in 64-bit mode? Supporting that would be the first step towards getting 16-bit and 32-bit modes out of the CPUs.
If the system was done like I suggested waiting until just before the deadline would give you a disadvantage. The longer you wait the higher the risk of missing the deadline. Putting in your bids early don't harm, they only gets published after the deadline. Additionally the system could allow you to modify your bids until the deadline if you should wish to do so, but there won't be any new information available within the system during that period, so it is unlikely to be of much benefit to be able to modify bids like that.
So, some people may not be accessing the market directly, but rather be trading by proxy (or whatever the technical term is for this sort of trading). Shouldn't change anything if the company you choose to proxy for you is trustworthy. But if you do trades through a company without any agreement about confidentiality, and if that company even utilizes information about your trades (which is not yet public) to optimize their own bids, then of course they get an advantage. That may not fall under the definition of insider trading, but it does sound like the same ballpark to me.
Nope, won't work. Laws of physics must be observed. Take your 10ns proposal and subtract the communication latency to find out how much time is left for computations. Turns out that the communication latency alone is going to be 3-8 orders of magnitude higher.
What you need to do to make the model workable is to consider the best case and worst case latency for the traders and use that to compute the best and worst case time available for computation. And it is the time available for computation, which must not differ by too many percents. Realistic numbers would be communication latencies between 100usec and 300msec. The best case latency is actually negligible, assuming it is zero will not affect the outcome of the calculations much.
Assuming 500msec per round with the above numbers the time left for computation would vary between 200msec and 500msec. That's 150% more time for the best case than the worst case, meaning traders with worst case latency must acquire hardware which is 150% faster to remain competitive. Increase the round duration to 2sec and the numbers now become 1700msec and 2000msec, only 18% difference.
The problem to be solved is this one. Trader A places, modifies, or cancels a bid. Trader B and trader C see the information about A's bid being published. In response to that change, both B and C want to place, modify, or cancel a bid of their own. But whether the change made by B or the change made by C gets to the exchange first can affect the trades happening.
This means whoever can get information about changes in bids and in response to that modify their own bids with the lowest latency has an advantage. I cannot see how that can be solved without introducing rounds.
In the above example it could be that B and C both want to trade with A and whoever gets there first gets to trade with A. But the updates that B and C want to make don't have to be about trades with A. It may just as well be that B and C could trade with each other or with a fourth party.
Read what I wrote again. There is no such thing as turns. In fact the word turn was not even used until you brought it up. There are rounds and each round everybody gets to place bids. Until the deadline of a round you get to place or modify your bids, but none of the bids are published until after the deadline. After the deadline all bids are published and trades are executed according to the bids.
In the simplest model bids are valid for a single round only, and if they could not be matched in that round they are automatically cancelled again. You have to keep placing the bid each round if you still want to be trading at the price of your previous bid. If you leave for lunch and don't have a computer refresh your bids while at lunch, you simply won't be trading for that duration.
In a slightly more complicated model bids are valid until a specified expiration time. Such bids are valid for multiple rounds, and if you want to cancel the bid before expiration, you have to explicitly cancel it. In each round a time stamp of the next deadline will be published, any active bids expiring after that deadline are still valid in the next round, unless cancelled before the deadline.
In principle the two models are the same. The expiration time is just an optimization. Without it traders would need a computer to republish their bid every round, which would consume some networking resources. But the more complicated model could trivially be simulated with the simpler model. If traders are going to update their prices each round, the benefit of bids valid for multiple rounds disappears.
The point of the model is that once information is published, there is a number of seconds until the next deadline, during that period everybody have the same public information to work with. There is no rush to submit bids, because any bid before the deadline is equally valid. A few microseconds more or less for computation isn't important when you have more than five seconds to complete the computation you need in order to place a bid.
Effectively each round is a double auction with secret bids.
I came up with the idea, but I think it is simple enough that others could easily have come up with it independently before or after me. So there may be detailed research of the idea, which I just don't know about.
There is a reason why people who need numbers that are provably random, compute a hash value of stock indexes. Wall Street has build the world's most sophisticated (P)RNG.
All these stories about traders needing ultralow latencies is a symptom of a fundamentally broken system. There are places where low latencies add value, stock trading is not one of them. Reduce the latency of everybody involved in the stock market, and nobody will have gained anything (except from the tech companies selling the technology being used).
The system should be modified to be round based rather than real-time. 10 seconds per round is long enough that all traders can have equal access regardless of how far they are from the stock exchange, and it is short enough that it won't be a hindrance to long-term investors. A round could spend a couple of seconds executing the trades, then publish the results, add another couple of seconds for communication, and traders will still have six seconds for calculations before the deadline for the next trading round.
With such a round based system you will change from competing on having the shortest distance to competing on having the best algorithms. Nobody will get an unfair advantage by having a shorter distance. Even if somebody does have one second more for calculations due to shorter distance, somebody further away can make up for that by a small increase in processing power. This is different from the latency based game, where no amount of processing power can make up for the additional latency.
The Latitude 13 I bought two years ago with Ubuntu preinstalled was significantly cheaper than the same machine with Windows. I don't remember the exact price difference, but I am pretty sure it was somewhere between 50 and 250$. It isn't the most durable hardware I have owned, and their customer support isn't stellar. But being able to buy a laptop with Linux preinstalled cheaper than the same hardware with Windows is worth something to me. I don't mind having to buy more expensive hardware to get something, which works with Linux. But that doesn't mean I want to pay more for the same hardware. Neither do I want to take part in funding all the things that Microsoft stands for. I may consider buying such an ultrabook once the price comes down.
Parent post is correct. Pages are not evaluated by people, but rather by an algorithm. And search results are not produced by people, but rather by an algorithm. But the algorithms don't magically appear. Those algorithms are written by people. But even smart people with good intentions cannot know if an algorithm is going to produce a good result or not. And this is where the human raters come into the picture. Their job really is to evaluate the variations of the algorithms introduced by the developers, to ensure that improvements to the algorithm make it through and other changes do not.
That is not exactly the situation I was referring to.
Any program a user installs for himself under his home directory should of course not be a thread to the overall security of the system. If it does, it is not the program that is to blame, but rather the OS. So it really should only put that user at risk. Some people are so paranoid about security, that they do not want non-administrator users to be able to write and run an executable. Any file system those users have write access to, should be mounted noexec. I think that is going too far, but a program should still be designed such that it can work in such an environment.
Even if it only threatens the user, who installed the program, there is however still some security issues. First of all you don't have as strong guarantees about timely updates. If the program is updated through a package manager, it will notice an update is available. If the program updates itself, it will only notice next time you start the program. So it takes longer time before you get the update. And that may be the time it takes for an exploit to be developed, which could hit the program in the time window from you start it until it realizes, that it needs updating.
However the main issue with this approach isn't the security threat, but rather that a program isn't supposed to contain code unrelated to the purpose of the program. If the purpose of the program isn't to install software updates, then it shouldn't contain code to install software updates. If every single program you install had its own code for installing software updates, you'd have loads of duplicated functionality, and with that many pieces of code intended to do the same thing, some of them are bound to be broken in some way.
The actual situation I was referring to was that of a program installed by root through a package file. That package file could be an rpm or deb file, which you downloaded from a website, or it could be found through a repository. When such a program is run by another user, it should not have any permissions to write to the package's files.
When I said "unlike other phones", it was not to be read as "unlike all other phones". Rather it was to be read as "unlike some other phones" or "unlike most other phones". I was merely pondering on the fact that it was considered newsworthy, that you can own a phone, which you have bought.
You can own a Nexus phone, you just have to buy it. Unlike other phones, which are still owned by the vendor even after they have been bought by a consumer.
The hacks needed in order to pull that off will put the security of the entire system at risk. This is something Linux distributions should fix. But the proper fix is not what those people behind self updating packages may have in mind. It needs to be fixed by not putting the same level of trust in every repository. The fix would break all the self-updating packages by removing their privileges to update themselves.
Only packages from repositories trusted by root, should be able to install files in directories from where they can be executed by root. Packages from other repositories shouldn't be able to install files in those directories, neither should they have any ability to install device inodes or files that are suid or sgid to root. And an update for a package mustn't come from a less trusted repository. Finally when a user logs in, the path should be set up to include only directories from those repositories that user trusts.
To give software distributors the right incentives, there should be tools making it easier to build packages and repositories. If it was easier to do things the right way and harder to do self-updating hacks, then we may see more software distributors do it right.
Remember most of those software distributors come with experience from Windows, where there is no right way of managing software. They take what they have learned on Windows and try to apply it to Linux. Though every Linux distribution actually has a right way of managing software, even a small learning curve may put off distributors and make them choose the hacks instead.
Because one case was about copyright and the other was about patents?
Now I see how instant runoff could have shortcomings compared to other methods. There is however a long list of criteria for elections. Each of those criteria in itself sounds very sensible and something you could reasonably require a voting system to satisfy. Unfortunately they are incompatible, and you cannot have a system satisfy all of them.
I am wondering, if there was to be an election to chose a voting system, how that would turn out. And should such an election chose a preference of the voting systems or a preference of the criteria characterizing good voting systems?
It is complicated, but that complexity shouldn't stand in the way of replacing a clearly inferior system with a better system.
That too. But eliminating that wouldn't solve the two-party problem. You'd need to remove the incentives turning it into a two-party party system from both the levels of the election. The two levels in the election is a left-over from a time where communication was a technical challenge. Today we have technology that overcomes all those hurdles. A direct vote with preferential voting would make the system much more democratic, and eliminate the two-party effect. Alas the people in a position to change it are exactly the people, who benefit from the two-party effect.
The problems mentioned in the Wikipedia article on first-past-the-post voting are solved by instant run-off. The most prominent problem is that first-past-the-post effectively is run-off voting with the first round of voting being done by the media rather than the voters. With run-off or instant run-off that problem is solved by taking that power away from the media and giving it to the voters. So I don't know which other problems you are referring to. Could you describe the problem, and how it could be solved?
What you describe is the reason why such systems turn into two-party systems. I don't think that is a very democratic system. There are different variations of voting systems that can improve that situation. The instant runoff, which you mentioned, is probably the best. I knew the system already (it is quite simple, any nerd would be able to come up with that design), but I didn't know the name of the system, so thanks for mentioning it.
I'd assume the countries, which have not yet banned those magnets, make up a sufficiently large market for at least one or two manufacturers of them to still be in business. I can't say whether it would then be legal for individuals to import some for their own entertainment.
No, but I think Route Origin Authorisations can help.
Oh, really? I thought Route Origin Authorisations were designed to address exactly this issue?
When have any of those things you mentioned other than nuclear war ever come close to happening outside of a sci-fi novel?
It does not only happen in sci-fi novels, it also happens in sci-fi movies. Somehow because it happens in sci-fi, lots of people think it is likely to happen in the real world as well. Why are people so easy to manipulate, that just because you make fiction about something, lots of people will actually perceive it as a real threat?
There are real threats to mankind, but I don't think mankind is a threat to life in general. We are a threat to specific species, including ourselves. But though we may cause many species to go extinct, I don't believe we could wipe out life on Earth. But is earthlife going to survive when the Sun boils away our oceans millions of years from now? If mankind goes extinct, will there be enough time for a new civilisation to develop the capability to travel through space in the Earth's lifetime?
You just gave another idea to those mad scientists out here that want to create a master race. Instead of diseases they`ll use meteors!
That is actually one of the possibilities in this game.