My bet is they're not a graphic designer. There's no reason to expect or even want them to mentor on blog aesthetics.
38,861 karma · joined February 4, 2010
In an interview he said the backlog has varied from 3 to 18 months. Pretty negligible in terms of his career advancement. This isn't something he wrote ages ago.
That's a purer form of current directory than cmd, which has one per drive.
Is there a reason one URL at a time wouldn't work?
In the same way that initializing a variable is overhead. But if you assume the variable will have a 7 in it because that's what it compiled to one time, it's not the compiler's fault when it compiles it to not be 7.
Except it's actually less overhead than that. You don't need to do any verification at runtime if your compiler cooperates. If it works like other pointers then you can get the same "base + delta * i" opcodes but without undefined behavior.
I shouldn't have used the word "check". A better way to phrase it is "knowing for sure". You need to know for sure where the goto is, which means using && and keeping track of what it tells you in some way.
> If the coder knows there will be four return values and writes them one after the other, the return (or MOV) instructions are distanced the same. The goto hack should work.
You can't know that. Sometimes other things will be in there, and sometimes the padding won't be so consistent.
Do what you're supposed to do. && every label you might jump to. And then you can check if they're spaced evenly at compile time. If they are you can treat them as spaced evenly at runtime.
The point of those comments is not to hype Lua, it's to show what a JIT can do.
The idea is that a python JIT could be just as good as Lua for the parts that aren't suited to numba.
> Lua is absolutely not faster than numba, nor will it ever be (absent a numba-like translation layer) and repeatedly trying to argue so is very much missing the point.
Nobody is arguing that. People are agreeing that numba is fast, but they also want other non-number-crunching things to be fast. It's "yes, and". They're not missing the numba point, they're agreeing and you're missing the additional point they're responding with.
That is not a config. That's a whole new program.
> My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
But with everything else you still made it sound like you were supporting it.
> I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
It satisfies it, but in a way that doesn't make the exploit overblown.
It's obvious that you can avoid a PHP exploit by turning off PHP. That's not nearly enough to make the worries overblown.
"It could be even worse" is the only conclusion we can draw from it being in php and not the web server. And that conclusion is basically meaningless.
Edit: From your reply of "Great work? Do you want a cert to prove how well you perform the function of forum peanut gallery?" it looks like you have abandoned the claim I was being suspiciously selective. Good! We're settled then. I'm going to ignore your weird new goalpost where you get annoyed that someone clarified themselves.
> which I’m sure surprises you
You caused the problem here. You started off being hazy and rude.
"Say that again without trying to dunk on anyone if you want me to put effort into responding." seems like a pretty reasonable trade.
It's not overblown if the only non-patch fix is "turn off PHP".
And that's assuming you actually meant "turn off PHP" the entire time? Your earlier phrasing suggests you have something that leaves PHP running in mind, but if that's entirely hypothetical then again we're back to misinformation. (And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix.)
Edit: stray "not"
PHP being big and creaky was very well known. This has nothing to do with hindsight.
And it still is big and creaky. You can cite this comment the next time something like this happens to prove it's not hindsight bias.
> And that is even with the assumption that other languages don't have issues
Incorrect. Please do not strawman.
Domestic production is good but sometimes big companies need to taste failure. We should lower the level of protection they're getting, at least for a while.
All else equal, a range that degrades from 300 to 230 miles is better than a range that starts at 210 miles and stays there forever.
It's not enough for finding a solution to be slower than verifying, it has to be slower by a particular extreme amount, and that has to hold for the best possible solution.
Also, there's a set of problems called NP-hard that you can convert any other NP problem into. For P≠NP we have to make sure all of the problems that are NP-hard have that speed difference (including the overhead from doing that conversion).
You can pick reference spot(s) and get it good enough.
> Note we're not talking about "below a millisecond" or below any other time range (second, minute, month). We're talking about _exactly_.
Ah, but we're not talking about exactly. Even when you're going for maximum accuracy, timestamps aren't generated at a particular instant. The gates in the computer coalesce over a cycle or two, if not longer. If you sync down to roughly the nanosecond, you hit max accuracy for CPU timestamps.
Though again, what's wrong with two CPUs that are n light-seconds apart having clocks that differ by at most n/10 seconds? You can't actually prove they aren't synchronized exactly, because of relativity.
There are things you simply can't write in C. I think that's okay. But even if you don't think that's okay, it doesn't conflict with zero-overhead.
-
But also, when it comes to jumping by address to a goto you didn't check is at that address, I'm on the side of the compiler here. That's not how computed goto is supposed to work. You're supposed to use an address you can know is right by reading the code.
A lot less than half of devices are broken when playing YouTube, I assure you.
If they stopped forcing it, it would still be the best choice most of the time. It doesn't "have to be" forced to be a major choice. The forcing changes the exact percentage but not the overall picture.