Um, no, that doesn't follow at all. Or did you fail to see that the sterilisation would only be for those who (a) carry the HIV virus and (b) have received a bone marrow transplant giving them artificial immunity?
No.
terilising these individuals would not cause culling of genetic variations at all -- compared to not giving them the bone marrow transplant in the first place, it's a zero sum.
No. HIV takes such a long time to kill its host, even if the host is vulnerable, that they would likely have time to get offspring. You are, in fact, trying to create artificial selective pressures here.
And even if you're opposed to restoring that equilibrium (fair enough), you're still not "culling 99% of genetic variations from humanity" by sterlising a small fraction of a percent of the human race.
If HIV will never spread to more than a "fraction of a percent" of the human race, then what use is your eugenics program, exactly speaking ? Trying to make people resistant to a virus they have almost no chance of contracting, and which can be cured even if they do ?
Transplanting bone marrow to a HIV-infected individual should, IMO, be followed by a mandatory sterilisation. Else, we will be working against natural selection, and will in the long run assist HIV in surviving by increasing the number of non-resistant individuals in future populations.
This is not only stupid but also logically absurd, for reasons outlined below.
First of all, HIV-immune people appear to compose some 1 percent of the population, at maximum. That means that you'd be culling 99% of genetic variations from humanity, leaving the remainder much more genetically uniform and thus vulnerable for the next pandemic. And let's not forget that "immunity to HIV" is not like a feat in a role-playing game; it is a result of the particulars of your biochemistry, and likely has side effects, such as extra vulnerability to some other disease.
Secondly, if bone marrow transplantation makes you immune, then having no inherent, natural immunity isn't significant - everyone who gets infected gets cured and HIV will run out of hosts and die out. Being vulnerable to a treatable illness is hardly rational grounds for sterilization.
Thirdly, why treat HIV specially ? There are lots of deadly diseases out there. Should we sterilize everyone who is not immune to any one of them - which, I'd hazard to guess, would mean sterilizing everyone ?
Finally, it is impossible to interfere with natural selection. Natural selection means that the fittest have most descendants, and fitness is defined as having lots of descendants. "Survival of the fittest" is a tautology, you can't alter it. The only thing you can do is alter the environment, which then alter which characteristics make you fit.
Frankly, I'm beginning to see the merit in removing evolution from school curriculum and replacing it with creationism or whatever. We've seen crap like this since when the theory was first introduced; while some of it was purposeful, at least some had to have been caused by honest stupidity. Only teaching it on university level might act as a filter to keep it away from people who'll figure it means they should start an eugenics program.
It would be very easy for an ISP to perform man-in-the-middle attacks on supposedly secure sites which use self-signed certificates.
'Very easy' if you are a cryptographer, but very difficult in practice.
Very easy for anyone: you simply set up an SSL-enabled proxy and redirect all Web traffic through it. Without certificates, you have no way of knowing whether you have an encrypted channel to the target server, or to a proxy which then talks to the server on your behalf and logs all the traffic passing through it. Any halfway competent network administrator can set that up in a matter of minutes.
That's the point of certificates: the Cone of Silence doesn't help you any, if the guy sitting opposite you is actually the enemy in disguise.
But to keep honest people honest and stop ISPs and others routinely eavesdropping on conversations, it works very well.
It doesn't, actually. Your ISP is guaranteed to be able to intercept each packet in the conversation, so they can use the above procedure.
It is certainly wrong to assert, as Firefox's current policy does, that an encrypted connection with a self-signed key is *less* secure than one in which all the data is sent in plaintext.
True; but it isn't significantly more secure either. It stops random relays from reading the packets passing through them, but does nothing against anyone attempting to spy on either you or the server you're connecting to specifically. It gives some protection against casual eavesdropping, but not against actual wiretapping.
Pick one or the other, AC, but not both: if they freeze to death, they can't have starved to death.
What if your inability to keep up your body temperature was caused by insufficient blood sugar and abnormally thin subcutaneous fat layer, caused by starvation ?
With this ambiguous new crime of "terrorism", it's too broad to define what you need to "nail'em" and get your desired outcome.
Then perhaps you should not charge people with "terrorism", but on murder, vandalism, etc.
I've never understood why "terrorism" needs special laws, when any kind of terror strike is already likely to run afoul of enough other laws to get you sent to prison for life. Even sending people flour in a letter could probably get you sued for harassment.
If anything, suing people for terrorism instead of murder only serves to validate the idea that someone who kill people for a political or religious ideology is somehow different than any other murderer, thus helping other would-be terrorists to justify their actions.
When on top of the endless bullying your cries for help go unanswered, you learn that you can't rely on anyone when you're in need, that no one cares about your well-being, and that people in practice have the right to mistreat you however they want.
I do not want to be expected to tell my children that "this is a part of life".
Unfortunately, it is, and the only part in fact. You either have the power to defend yourself or you don't; in the latter case you're abused by everyone and either live with it or die.
The sick thing is that people dream of things being different; just look at how popular variations of the "hero who crushes evil and sets things right" story are, or romance stories, or the like; but in reality, when push comes to show, or when they're simply bored, these same people are the very demons who make this world a living hell.
Dream of heaven but act to make the world around yourself a hell; I guess that means that people are insane.
Well, making all the prisoners read a book about how someone who's imprisoned on false charges gets revenge might help weed out and discourage the corruption in the police...
I would be thrilled to see all prisoners learn a trade and once they were released, they could be a productive citizen. In its current form, prison sentences aren't doing this. This is why I advocate making prison harder.
This will simply make the "mark of honour" more valuable, as well as produce hardened criminals. It won't deter crime, thought; the Romans, with their habit of crucifying criminals or feeding them to lions in their softer moments, couldn't do it, so neither can you, no matter what you make the punishment into.
Oh, and harder punishments also give criminals more incentive to kill the witnesses.
That sounds like something a communist would say. You aren't a communist, are you, comrade ? Because the way you talk about your rightful Czar and government sounds just like what a communist rebel terrorist would say.
Your bolshevik sympathies and rebellious attitude have been noted. We're watching you. -Ohrana
The reason our troops are so effective is because they can think on their feet.
I guess that's why they're developing artificial intelligence;).
Besides, your army already uses robots: cruise missiles, automated defence systems, etc. "Virtual soldier" is a logical extension of this, and I can think of many uses for them, most of which revolve around the fact that they're expendable. Or wouldn't you rather send a lookalike before you if you suspect an ambush ?
Having lots of artificial soldiers smart enough to obey simple commands but not smart enough to care or get anyone else to care whether they live or die is a boon for commanders, because it helps keep non-artificial soldiers out of the most dangerous spots. This might also help reduce civilian casualties, since such cheap constructs can be instructed to risk on the side of getting gruesomely killed if they are unsure whether they should fire or not. You don't get the whole "is this guy shooting at me an enemy fighter or a father of three protecting his family" -scenario; you can simply send ten bots to disarm him without hurting him, and if a few get shot to pieces, so what ? A human soldier would have a rather nasty choice before him there.
If the VM started running on a Xeon Harpertown and moved to an AMD Santa Rosa, then to a Core 2 Quad Yorkfield, which features should be enabled/disabled in each move?
After each move, compare the current hosts featureset with the original hosts featureset, and emulate all that are missing.
Your original claim was: "This is because you have no way of knowing which processor type the VM was first started on." That is clearly untrue, since you can pass the CPUID information of the original processor right along with the VM, and thus let the receiver know what CPU the OS thinks it is running on, thus negating your conclusion: "And, when you think about it, any instruction that you would have to trap if the VM used to be running on a different processor must be trapped at all times."
Of course you take a performance hit from emulation, and would be better off to pass VM's to as compatible - preferably identical - CPU's as possible; however, sometimes the cost of the overhead of emulation might be less than the cost of rebooting the VM, or keeping an obsolete type of machine working, and in that case it would be nice to be able to migrate the VM to another type of processor. Passing the CPU type information along with it lets the receiver know what special instructions - if any - need to be emulated, thus only incurring the overhead when it is actually necessary.
This, of course, all depends on whether you meant what I think you meant.
This is the sort of "trivial" that is only used by pure mathematicians. In practice, it's much harder than that, especially when modeling any program with non-determinism in it (almost all of them these days).
A Turing machine is completely deterministic - that is, for the given input and algorithm, it will always return the same result, or never return. A non-deterministic program is not a Turing machine, and as such the halting problem doesn't apply.
Of course it might still be impossible to determine whether such a program returns or not - in fact it likely is, since that's what "non-deterministic" strongly implies, but that has nothing to do with "the" halting problem.
The problem is two-fold. Firstly, working out when two states are the same is a much harder challenge than it first appears: e.g. does it matter that the system clock has advanced in the meantime?
Depends on the program, obviously. The simple method I outlined tracks all internal storage, including any and all clock counters, as part of state.
Secondly, the state space grows massively fast and storing all the states of even a small program tends to lead to a memory structure that is very inefficient (you get a fully random access memory pattern across data that is too large even to fit on a substantial modern cluster...)
Of course. I never said it was a practical solution. I simply pointed out that the halting problem is only unsolvable given infinite storage (translating into infinitely many different states) for the target machine.
I say this as someone who has (a few years ago now) written deadlock checkers and temporal logic model checkers for real programs.
From what I've understood, a deadlock can only occur if, for any pair of locks, they can be acquired in either order, and not otherwise. This, then, seems to suggest that they are simple to avoid: just put all the locks in your program into an ordered list and make sure that no thread can ever attempt to get a "lesser" lock than the highest-numbered one it currently has. Maybe make a custom locking function which keeps track of the highest lock number, and terminates the thread (or just returns an error) and complains loudly into the log if locking a lower-numbered lock is attempted ?
You could also base the checking algorithm on this: just make sure there are never in any code path any inconsistencies in the locking order, and it should work fine.
Perhaps we should try electing people with above room temp IQs. Anyone think that will work?
The more intelligent and competent people you elect, the better they are able to circumvent any obstacle in their quest for power, and the harder it will be for you to circumvent the obstacles they throw in front of you. Consequently, it would only make things worse.
Is there any reason you couldn't keep a list of processor dependent memory locations and regenerate them for the current machine as part of the migration?
The halting problem?
The parent is not talking about a general algorithm which could determine whether any other algorithm halts, he's talking about translating the state of an algorithm from one specific approximation of a Turing machine to another. These problems have nothing to do with one another.
Besides, the halting problem only applies to an actual theoretical Turing machine, which has an infinite storage available. Solving the halting problem for a finite-storage Turing machine approximation is trivial: simply trace the algorithm and compare each state it reaches with each previous state. If the states are identical, then the algorithm will never terminate, for it has entered an infinite loop. If a machine has, for example, only 2^32 bytes of storage available, then it only has 2^(32*8) different possible states, and is thus guaranteed to either exit or repeat a state after a finite number (2^(32*8)) of state transformations. A true infinite-storage Turing machine has infinite number of possible states, so it is not possible to use this approach with it.
Finally, even in a true Turing machine, the halting problem does not state that you can't reason about a particular algorithm; it simply states that you can't write an algorithm which automatically proves for an arbitrary algorithm and input that it'll halt.
I wonder if the abuse of the halting problem will ever end ?
So guess how hard it will be to get them to run a perl script as root - either via sudo or other means.
Why would it need to run as root ? Running as a regular user, it can:
Start as soon as the machine starts by simply adding itself to the user's crontab.
Access the network, both TCP/IP and UDP/IP, and use all protocols that run on top of these.
Read the user's address book.
Listen to user's keystrokes and mouse movements, as well as take screenshots (but probably not if written in perl).
Attach itself as a debugger to any process owned by the user (such as the web browser), and read and control their internal state (but probably not if written in perl).
Add the fact that Gnome starts a shitload of processes with weird names to help mask the virus process, and I can see no reason whatsoever why a Linux virus would need or even want root privileges. About the only thing it can't do is send raw ICMP packets. That would be useless anyway, since exploiting holes in kernel networking stack would make said holes get fixed very fast indeed.
Re:The idea is to move from 'play' to 'life'
on
How Do Games Grow Up?
·
· Score: 2, Insightful
DISCLAIMER: I believe video games as a hobby or habit to be a tragic waste of time for anyone over 15.
That rises the question of why you are participating in a discussion about video games. It also rises the question of "Why": What criterion would use of time need to satisfy in order to not be considered "waste" by you, and why ?
Games, those which are purely for amusement, belong to the children.
A bold claim. Can you back it with reasoning ?
Exploring (safe) challenges and developing the mental capacity to overcome them is the net benefit from puzzles, games, and the like.
Being entertained is a goal in itself, meaning that it satisfies a feedback loop in your brains, which is interpreted as a reward by them. Benefits towards meeting your other goals are a nice bonus, but not really necessary.
Once the neural pathways have been created, it's time to move from 'play' to 'life'.
"Play" and "life" are not mutually exclusive, you know. And what, exactly speaking, makes being successful in life superior to being successful in a game ? Both bring you satisfaction, and both are ultimately fleeting moments.
Children who play at occupational games, work to solve mental and logic challenges, and experience success have something meaningful and real to take into adulthood.
"Meaningful" and "real" are useless in a discussion such as this, since what is meaningful to me isn't necessarily meaningful to you, or the other way around. And while "real" has an objective meaning, it seems that you meant it in some vague philosophical sense, rather than the objective one.
Perhaps you meant "useful" - the term "occupational game" hints that way - but that then rises the questions of: useful towards what end ? And why is that end more worthy of pursuing that the entertainment from playing games just for amusement ?
Play until you know what to do, then step up to "Do." Leave the toys behind, or make new ones for the up-and-coming crew.
What purpose, exactly speaking, does this serve ? What is it that you want us to "Do", and why should we ?
The eeePC showed that linux works fine as a preinstalled OS. Its driver structure doesn't change every release in an unpredictable way.
Yes it does. If your driver isn't included in the kernel source tree, it will stop working at random releases as some API is removed or changed. This is true even for drivers distributed entirely in source form; for binary drivers it is nothing short of a nightmare.
This is an especially large problem for video cards. For other components, you can pick ones Linux has in-kernel support for, but there is not a single decent 3D card included in that list. Add the fact that NVIDIAs newer drivers have dropped support for legacy cards, and I'm apparently forced to upgrade my machine if there's a critical kernel bug.
He or she is saying that people who don't succeed will find any loophole that enables them to blame their inability to succeed on others.
They'll try to find a loophole but won't have much success there. And it's your fault they'll fail, since you exposed their plot, you oppressive bastard.
Slashdot Mirror
No.
No. HIV takes such a long time to kill its host, even if the host is vulnerable, that they would likely have time to get offspring. You are, in fact, trying to create artificial selective pressures here.
If HIV will never spread to more than a "fraction of a percent" of the human race, then what use is your eugenics program, exactly speaking ? Trying to make people resistant to a virus they have almost no chance of contracting, and which can be cured even if they do ?
I believe that's what the grandparent meant by "invading other nations".
Which will then proceed to attack every cell in your body since it recognizes them as "alien".
This is not only stupid but also logically absurd, for reasons outlined below.
First of all, HIV-immune people appear to compose some 1 percent of the population, at maximum. That means that you'd be culling 99% of genetic variations from humanity, leaving the remainder much more genetically uniform and thus vulnerable for the next pandemic. And let's not forget that "immunity to HIV" is not like a feat in a role-playing game; it is a result of the particulars of your biochemistry, and likely has side effects, such as extra vulnerability to some other disease.
Secondly, if bone marrow transplantation makes you immune, then having no inherent, natural immunity isn't significant - everyone who gets infected gets cured and HIV will run out of hosts and die out. Being vulnerable to a treatable illness is hardly rational grounds for sterilization.
Thirdly, why treat HIV specially ? There are lots of deadly diseases out there. Should we sterilize everyone who is not immune to any one of them - which, I'd hazard to guess, would mean sterilizing everyone ?
Finally, it is impossible to interfere with natural selection. Natural selection means that the fittest have most descendants, and fitness is defined as having lots of descendants. "Survival of the fittest" is a tautology, you can't alter it. The only thing you can do is alter the environment, which then alter which characteristics make you fit.
Frankly, I'm beginning to see the merit in removing evolution from school curriculum and replacing it with creationism or whatever. We've seen crap like this since when the theory was first introduced; while some of it was purposeful, at least some had to have been caused by honest stupidity. Only teaching it on university level might act as a filter to keep it away from people who'll figure it means they should start an eugenics program.
Very easy for anyone: you simply set up an SSL-enabled proxy and redirect all Web traffic through it. Without certificates, you have no way of knowing whether you have an encrypted channel to the target server, or to a proxy which then talks to the server on your behalf and logs all the traffic passing through it. Any halfway competent network administrator can set that up in a matter of minutes.
That's the point of certificates: the Cone of Silence doesn't help you any, if the guy sitting opposite you is actually the enemy in disguise.
It doesn't, actually. Your ISP is guaranteed to be able to intercept each packet in the conversation, so they can use the above procedure.
True; but it isn't significantly more secure either. It stops random relays from reading the packets passing through them, but does nothing against anyone attempting to spy on either you or the server you're connecting to specifically. It gives some protection against casual eavesdropping, but not against actual wiretapping.
What if your inability to keep up your body temperature was caused by insufficient blood sugar and abnormally thin subcutaneous fat layer, caused by starvation ?
Then perhaps you should not charge people with "terrorism", but on murder, vandalism, etc.
I've never understood why "terrorism" needs special laws, when any kind of terror strike is already likely to run afoul of enough other laws to get you sent to prison for life. Even sending people flour in a letter could probably get you sued for harassment.
If anything, suing people for terrorism instead of murder only serves to validate the idea that someone who kill people for a political or religious ideology is somehow different than any other murderer, thus helping other would-be terrorists to justify their actions.
Unfortunately, it is, and the only part in fact. You either have the power to defend yourself or you don't; in the latter case you're abused by everyone and either live with it or die.
The sick thing is that people dream of things being different; just look at how popular variations of the "hero who crushes evil and sets things right" story are, or romance stories, or the like; but in reality, when push comes to show, or when they're simply bored, these same people are the very demons who make this world a living hell.
Dream of heaven but act to make the world around yourself a hell; I guess that means that people are insane.
Well, making all the prisoners read a book about how someone who's imprisoned on false charges gets revenge might help weed out and discourage the corruption in the police...
This will simply make the "mark of honour" more valuable, as well as produce hardened criminals. It won't deter crime, thought; the Romans, with their habit of crucifying criminals or feeding them to lions in their softer moments, couldn't do it, so neither can you, no matter what you make the punishment into.
Oh, and harder punishments also give criminals more incentive to kill the witnesses.
That sounds like something a communist would say. You aren't a communist, are you, comrade ? Because the way you talk about your rightful Czar and government sounds just like what a communist rebel terrorist would say.
Your bolshevik sympathies and rebellious attitude have been noted. We're watching you. -Ohrana
I guess that's why they're developing artificial intelligence ;).
Besides, your army already uses robots: cruise missiles, automated defence systems, etc. "Virtual soldier" is a logical extension of this, and I can think of many uses for them, most of which revolve around the fact that they're expendable. Or wouldn't you rather send a lookalike before you if you suspect an ambush ?
Having lots of artificial soldiers smart enough to obey simple commands but not smart enough to care or get anyone else to care whether they live or die is a boon for commanders, because it helps keep non-artificial soldiers out of the most dangerous spots. This might also help reduce civilian casualties, since such cheap constructs can be instructed to risk on the side of getting gruesomely killed if they are unsure whether they should fire or not. You don't get the whole "is this guy shooting at me an enemy fighter or a father of three protecting his family" -scenario; you can simply send ten bots to disarm him without hurting him, and if a few get shot to pieces, so what ? A human soldier would have a rather nasty choice before him there.
Well, as long as he doesn't laugh while sending people to be executed, he'll still be an improvement.
After each move, compare the current hosts featureset with the original hosts featureset, and emulate all that are missing.
Your original claim was: "This is because you have no way of knowing which processor type the VM was first started on." That is clearly untrue, since you can pass the CPUID information of the original processor right along with the VM, and thus let the receiver know what CPU the OS thinks it is running on, thus negating your conclusion: "And, when you think about it, any instruction that you would have to trap if the VM used to be running on a different processor must be trapped at all times."
Of course you take a performance hit from emulation, and would be better off to pass VM's to as compatible - preferably identical - CPU's as possible; however, sometimes the cost of the overhead of emulation might be less than the cost of rebooting the VM, or keeping an obsolete type of machine working, and in that case it would be nice to be able to migrate the VM to another type of processor. Passing the CPU type information along with it lets the receiver know what special instructions - if any - need to be emulated, thus only incurring the overhead when it is actually necessary.
This, of course, all depends on whether you meant what I think you meant.
A Turing machine is completely deterministic - that is, for the given input and algorithm, it will always return the same result, or never return. A non-deterministic program is not a Turing machine, and as such the halting problem doesn't apply.
Of course it might still be impossible to determine whether such a program returns or not - in fact it likely is, since that's what "non-deterministic" strongly implies, but that has nothing to do with "the" halting problem.
Depends on the program, obviously. The simple method I outlined tracks all internal storage, including any and all clock counters, as part of state.
Of course. I never said it was a practical solution. I simply pointed out that the halting problem is only unsolvable given infinite storage (translating into infinitely many different states) for the target machine.
From what I've understood, a deadlock can only occur if, for any pair of locks, they can be acquired in either order, and not otherwise. This, then, seems to suggest that they are simple to avoid: just put all the locks in your program into an ordered list and make sure that no thread can ever attempt to get a "lesser" lock than the highest-numbered one it currently has. Maybe make a custom locking function which keeps track of the highest lock number, and terminates the thread (or just returns an error) and complains loudly into the log if locking a lower-numbered lock is attempted ?
You could also base the checking algorithm on this: just make sure there are never in any code path any inconsistencies in the locking order, and it should work fine.
The more intelligent and competent people you elect, the better they are able to circumvent any obstacle in their quest for power, and the harder it will be for you to circumvent the obstacles they throw in front of you. Consequently, it would only make things worse.
Actually, it's exactly the other way around. People get used to constant minor attacks, while rare but flashy attacks cause shock and awe.
The parent is not talking about a general algorithm which could determine whether any other algorithm halts, he's talking about translating the state of an algorithm from one specific approximation of a Turing machine to another. These problems have nothing to do with one another.
Besides, the halting problem only applies to an actual theoretical Turing machine, which has an infinite storage available. Solving the halting problem for a finite-storage Turing machine approximation is trivial: simply trace the algorithm and compare each state it reaches with each previous state. If the states are identical, then the algorithm will never terminate, for it has entered an infinite loop. If a machine has, for example, only 2^32 bytes of storage available, then it only has 2^(32*8) different possible states, and is thus guaranteed to either exit or repeat a state after a finite number (2^(32*8)) of state transformations. A true infinite-storage Turing machine has infinite number of possible states, so it is not possible to use this approach with it.
Finally, even in a true Turing machine, the halting problem does not state that you can't reason about a particular algorithm; it simply states that you can't write an algorithm which automatically proves for an arbitrary algorithm and input that it'll halt.
I wonder if the abuse of the halting problem will ever end ?
Why ? Is there any particular reason you can't send this information along with the VM itself ?
Why would it need to run as root ? Running as a regular user, it can:
Add the fact that Gnome starts a shitload of processes with weird names to help mask the virus process, and I can see no reason whatsoever why a Linux virus would need or even want root privileges. About the only thing it can't do is send raw ICMP packets. That would be useless anyway, since exploiting holes in kernel networking stack would make said holes get fixed very fast indeed.
That rises the question of why you are participating in a discussion about video games. It also rises the question of "Why": What criterion would use of time need to satisfy in order to not be considered "waste" by you, and why ?
A bold claim. Can you back it with reasoning ?
Being entertained is a goal in itself, meaning that it satisfies a feedback loop in your brains, which is interpreted as a reward by them. Benefits towards meeting your other goals are a nice bonus, but not really necessary.
"Play" and "life" are not mutually exclusive, you know. And what, exactly speaking, makes being successful in life superior to being successful in a game ? Both bring you satisfaction, and both are ultimately fleeting moments.
"Meaningful" and "real" are useless in a discussion such as this, since what is meaningful to me isn't necessarily meaningful to you, or the other way around. And while "real" has an objective meaning, it seems that you meant it in some vague philosophical sense, rather than the objective one.
Perhaps you meant "useful" - the term "occupational game" hints that way - but that then rises the questions of: useful towards what end ? And why is that end more worthy of pursuing that the entertainment from playing games just for amusement ?
What purpose, exactly speaking, does this serve ? What is it that you want us to "Do", and why should we ?
Yes it does. If your driver isn't included in the kernel source tree, it will stop working at random releases as some API is removed or changed. This is true even for drivers distributed entirely in source form; for binary drivers it is nothing short of a nightmare.
This is an especially large problem for video cards. For other components, you can pick ones Linux has in-kernel support for, but there is not a single decent 3D card included in that list. Add the fact that NVIDIAs newer drivers have dropped support for legacy cards, and I'm apparently forced to upgrade my machine if there's a critical kernel bug.
That is true for all words and terms.
They'll try to find a loophole but won't have much success there. And it's your fault they'll fail, since you exposed their plot, you oppressive bastard.
Red Alert: Winter War ?-)