If this isn't unnecessarily "snarky" itself, then what is it?
snarky: (of a person, words, or a mood) sharply critical; cutting; snide.
Since you take a different view though, as I asked in my post, if it's not "snarky" then what was it?
Despite the avalanche of downvotes burying my posts, not even one person can actually answer the question I asked:
The poster could have simply stopped typing after "Thank you for the explanation". He chose to unnecessarily add something more.
So, for everyone who disagrees with me: if what he said wasn't itself "snarky", what was it?
A complaint that Hacker News is a less agreeable place than it used to be. Whether that's true or not, don't you think you might find a more effective way of counter-arguing than by being as disagreeable as you can possibly manage without outright swearing in your responses?
I get that you're sure that you're right. That's great! That's a source of strong motivation to pursue an argument. But it suffices really nothing just to say "I'm right", and much less just to say "you're wrong". If you're interested in convincing people that the argument you're advancing is a more accurate model of reality than those with which it's contending, then you have to do just that - convince people, by answering their points with compelling counterarguments of your own.
And if you want to shape the discussion such that it's possible for you to convince anyone of anything, then you must above all treat your interlocutors with impeccable respect, no matter how wrong you may think - or know! - they are. To do otherwise only hardens them against whatever you may have to say, and the outcome you thus produce is even less favorable than that of simply declining to engage in the first place. Conversely, treating those around you with respect tends very strongly to elicit respect toward you from them, in turn. That's how you earn the fair hearing you need to make arguments that might convince, and thus give yourself a place to start.
Perhaps that sounds like a normative, rather than a positive, statement. I've seen people react badly in the past, and sling accusations of "tone policing" and all manner of other offenses against some apparently very abstract conception of discursive mores which may hold sway in occasional quarters but is very far from predominating. I'm not telling you how you should behave in the sort of discourse where "tone policing" is a meaningful phrase - indeed I'm not telling you how you should behave at all. What I'm telling you is that, whatever places you may have been where you found unstinting contempt for your interlocutors to serve your turn, none of those places is here.
That's why hectoring people, as I have observed you fairly consistently to do here, doesn't convince people of your points. At most it convinces them to stop trying to talk with you. Perhaps that's the result you're trying to produce, in which case keep doing what you're doing! But if you're not trying to develop for yourself a reputation here of being someone best avoided, then you may wish to revise your style of argumentation somewhat.
Now before you get too cross with me saying this as I have, consider: We spoke briefly the other day on the subject of complaining about downvotes and why it is not helpful. You seem genuinely upset to accrue them so easily, and I treated that dismay perhaps more cavalierly than was justified. I'm sorry for that; to try to make up for it, I thought I'd explain why it is they keep happening and what you can do to change that.
You clearly expect respectful engagement from others, and there's nothing wrong with that. But when you refuse to engage respectfully with others, who quite reasonably expect the same, it isn't really a surprise when people choose to answer that disrespect by downvoting and moving on, rather than by eliciting your further contempt through an attempt to engage with you.
The good news is that you have in your hands the power to change this state of affairs! The style of your discourse is entirely within your control. Show respect to those around you, and you'll find those around you show you respect in return. You can totally do that! You can totally make that happen. I hope you'll choose to do so.
Which makes the place no more agreeable.
> Whether that's true or not... <huge snip>
This is amazing.
I ask a question, and the only "answer" is simply an excuse to segue into a weird, patronizing, passive-aggressive wall of text that has zero to do with what I actually posted, and is nothing but a personal attack dressed up as a lecture on politeness. Amazing.
I guess you don't reach 10k karma on a throwaway by not having a gallery to play to.
I think the frightening thing about meltdown/spectre is the ability for code to escape otherwise solid sandboxes - including VMs, as well as javascript runtimes. It's a change in the threat landscape for systems which expect to run remote code but believe they can do so safely.
They're using a "monolithic" cloud provider and don't have a choice in their current deployment?
The most secure computer is powered off, enclosed in concrete 6 feet below the surface of the earth. It is not very useful though.
"100% secure" is unattainable, and to attempt to achieve it to the exclusion of all other concerns is probably a very bad idea.
If you’re not going to apply patches that close privilege escalation bugs, you might as well. You’re putting all your security eggs in one basket.
Then you didn't listen to DJB like 15 years ago. Moreso, your processes shouldn't be running under the same username. Principle of least user authorization people.
We know how Unix works. We’re telling you because you clearly are out of your depth. If you don’t understand that you have no business maintaining anything on the internet.
I also think that we need more information before we really see the long-term performance impact here. First, the patches will likely be optimized over time. Second, I am not sure that PTI needs to be run within guest kernels if the host already has the mitigation (effectively creating a double-hit from PTI in both the guest and host kernel), or that even if PTI is needed in both kernels now, that it will be needed long-term. We also need to figure out what type of Spectre mitigations need to be performed within the guest if the host system has the new microcode that selectively disables branch prediction.
The short answer is that it's going to take another 4-6 weeks before even the kernel devs have a firm grasp of what's useful/necessary to mitigate this and for things to settle into place, as Greg K-H blogged about earlier. At that point, we should have a more realistic perspective on the long-term performance impact.
Strongly disagree. No single defense measure is infallible and defense in depth has proven one of the most important topics in computer security.
Regardless of what some of my customers believe patches are rarely hand picked and then applied. All security patches are applied, always, kernel patches even more so. They are rolled out with the tools provided by the operating system, be it Windows, Redhat, Ubuntu, OpenBSD, Solaris or whatever, and they don't make assumptions about your use case, they just apply all security patches.
Have you ever heard of the term 'buffer overflow'?