pingyong

The distinction between "people who participate" and "people who practice" is basically impossible to make, even just in video games.

Even the example he gave didn't really work: He says that the top 30% of players in Overwatch can reasonable be expected to want to win. Which I agree with (it's probably an underestimation) - but does this mean that the bottom 70% only "participate"? Because that would mean to get into the 95th percentile of "people who practice", you would have to be in the 1.5th percentile of Overwatch players.

Another layer of this problem exists when you look at people who play the game regularly, but don't play ranked. On average, those players are probably worse - but should they be included in the percentile?

Ultimately the percentile thing just doesn't make much sense, but I still think the overall message of the blog post, that most people could improve at something they do at a much faster rate if they were willing/able to really focus on improving themselves and less on external factors that they can't control, is absolutely true.

I genuinely cannot tell if this is supposed to be satire or not.

Honestly, it really just depends on what their "hardcore coding test" actually entails.

If they give you like 1 short task that you're supposed to solve on a white board, well, that doesn't really map well with what you're actually supposed to do.

But if they sit you down for 8 hours with a reasonably interesting task (both optimization and architecture wise), that's a pretty decent filter. It just takes a lot of time and effort from both the company and the candidate so almost nobody does it.

It's not like the usual filters (engineering experience or education) are this amazing gold standard either. Just because someone wrote barely passable C++98 code for 15 years that doesn't make him a great programmer, and neither does having degree.

Sure but that's going to mainly depend on where their energy comes from, not how much they use.

A cloud provider that specializes in compute will have vastly higher energy costs than a cloud provider that specializes in storage. Even without explicit specialization, it's not unreasonable to assume that the distribution of compute-heavy and storage-heavy customers is quite different between providers. So you'd have to sort of calculate that out.

But if you do that, I'm not sure what would even differentiate them. They're all using essentially the same hardware. They all have the same cooling requirements. I wouldn't expect an average to be very interesting.

While I completely agree with that in general, the opportunity for practicing it is unfortunately seldom a reality. I mean you need to be in a situation where

- You're designing a new product, or relatively large / independent new feature of a product.

- You also have a decent amount of time to think about it, maybe experiment with some performance characteristics, and not be under pressure from "management" (or whoever else) to have a "working" demo version quickly so they can actually show and sell it to people.

Sure it happens sometimes, and it's great, but I would argue for most programmers this isn't their daily reality.

It should be noted that the client and the game are two completely separate pieces of software. The game itself certainly has a bunch of bugs, but those bugs tend to not be game-breaking, and are mostly "this doesn't behave as described" - for many of these things, it's not even clear anymore what the intended behavior even is. Until it's fixed, it's intended, for better or worse.

But apart from that, the game is actually somewhat bug free.

The client however, is just an honest to god embarrassment. It is legitimately terrible in every aspect that could possibly be terrible. It's slow, so slow that many things temporarily break on laptops, like opening rune pages in champion select. It uses more RAM than the game itself (?), it runs on like 4 different processes that interact in who knows what ways, but if the client crashes and you're trying to kill it that often (but not always) initiates a repair for no apparent reason. Often it doesn't even shutdown properly when you close it. On a friend's computer it one day just died and didn't start at all anymore, with no indication of what went wrong. He had to reinstall the game.

https://www.reddit.com/r/leagueoflegends/comments/epm9c8/all...

It's a mess. And not only it is it a mess, it's an embarrassing mess because the client was always a pain point of many players, until they decided to completely re-write it in 2015. From the ground up. Clean slate - scalable, durable, lightweight, all that jazz. And now it's widely regarded as worse than the original client. If there was ever an example of how not to rewrite something, that would be it. Just a catastrophe on every level.

Why wouldn't you though, that's gotta be pretty juicy data. You can compare phone numbers across so many different databases now, makes profile creation 10x more efficient. Not really surprising that everyone wants your phone number badly these days.

Microsoft does the same thing btw. Was really fun for a friend of mine who registered a Microsoft account for mixer, forgot about, bought Halo, needed an MS account to log in, thought hey I already have one, and instantly got locked out because it didn't have a phone number.

It should be noted that there are multiple mechanics at play here, and neither was removed completely.

The first mechanic is that while jumping, when you either hold down the A-button and move your mouse left at the right pace, or hold down the D-button and move your mouse right at the right pace, you will accelerate slightly, plus change your trajectory.

The second mechanic is that you don't just stop when you hit the ground, instead friction is applied to you in a very simplistic way. Also, when you jump at exactly the same tick at which you hit the ground, this friction won't even be applied.

Both mechanics together mean that you can reach theoretically unlimited velocity.

I'm not entirely sure what the changes in 1.3 were, but certainly both mechanics still exist in 1.6.

The first mechanic you can easily test on a local server, by typing "sv_gravity 0" into the console, then jumping into the air and performing the motions mentioned above - you can still reach unlimited speed.

The second mechanic is harder to test, but I'm pretty sure it still works. However, it might only work for a single time or something like that.

There is also "sv_airaccelerate" which somehow controls how much you accelerate with mechanic 1, but I'm not exactly sure how it works.

One thing though that I always mention when this comes up: Mechanic 1 doesn't just make gameplay better, it actually makes it more realistic too, and it should be implement in every shooter. "But I can't jump around corners in real life!" you might say, however I would argue that you actually can. We can do this because we can use both of our feet to manipulate our trajectory much more finely that we can in most games.

All mechanic one does is give us this lost freedom of motion back.

>Status-quo If a signed operation would naturally produce a value that is not within the range of the result type, the behavior is undefined. The author had hoped to make this well-defined as wrapping (the operations produce the same value bits as for the corresponding unsigned type), but WG21 had strong resistance against this.

I really don't understand why WG21 is against this, do you happen to have a link to arguments against it? The only one I frequently see is that "it's faster that way" with a link to godbolt where iterating with a 32-bit signed integer on a 64-bit system is faster than iterating with a 32-bit unsigned integer, because the compiler exploits UB here to ignore overflow. Which is of course a completely useless example because simply using a correctly sized integer for iteration, signed or unsigned, will always result in the fastest most correct code.

I'm not aware of any other arguments against it.

The new coronavirus is probably about as deadly as the seasonal flu, by the way. ;)

Furthering the M&M analogy: Let's say you have a box with 10,000,000 M&Ms. 1000 of them are poisonous, and of those 1000 10 are deadly, 290 make you sick for a week, and 700 will mildly inconvenience you for a day.

My point is that removing UB is like removing 1 deadly, 20 sickening, and 70 inconveniencing M&Ms. Which, by every metric, is a great thing. The only thing that bothers me is that some people act like removing UB is equivalent to removing all 10 deadly M&Ms, which obviously isn't the case.

Is this really such a big deal mentally? Idealized there are only two behaviors: Expected and unexpected. Whether that unexpected behavior is a result of UB, or implementation defined behavior, or logic errors, or unforeseen corner cases, doesn't in practice actually matter. Your computer isn't actually any more likely to cause a nuclear explosion because it hit UB than it is to do that because it hit some other kind of bug.

Of course reducing and any kind of bug class is a plus, Rust is great, but I never had the feeling that my C++ code is more error prone than my Java or Python code just because some things are completely UB. What actually happens with UB is that the application crashes and/or data gets scrambled - I've yet to see my PC to feel free to stand up and walk away just because it was technically allowed to.

I wonder if this knock-off problem I keep reading about is something specific to the US. I've ordered ~200 things over the last 3 years from Amazon, and I've never received a knock-off either. I've never even heard of that happening outside of internet comments. Plus sending things back to Amazon is usually fairly trivial.

That is not the goal of mGBA (or any GBA emulator for that matter), btw. If you wanted to reproduce it faithfully, the emulator would be unusably slow.

https://emulation.gametechwiki.com/index.php/Emulation_Accur...

>but that's distinct from the overall windowing system, graphics state, etc. which would be stored in `World`.

That'd be pretty odd naming, usually 'World' would own all your game objects and scene, but have no relation to the windowing system or swap chain.

Regardless though, I wouldn't make the windowing system or swap chain or d3dcontext global either, I mean all of that is literally designed to be wrapped into some object. (Well, the window requires some trickery, but it's still prettier than a global handle in the end.) There's really no reason for a game to have actually global state, even if most games are only going to need one window.

Maybe there should always be a way to open a bank account, even without a home address? If you don't have a bank account, you get excluded from a lot of options that might solve your homelessness anyway. It seems to me that being able to open a bank account should be a fundamental right of some sort.

>That should have been plainly obvious to any technically knowledgeable user because you don't lose your data forever when you forget your Apple ID password. Or the fact that you can see your photos through a web browser on icloud.com

You could build a system where there's a key stored on each of your devices, and your password also acts like a key. In that case, you could

- Lose all your devices, but unlock with password

- Forget your password, but unlock with any device

- Lose one device, but unlock with your password or any other device

Of course, most people's passwords would probably be way to weak, no matter how much time Apple spends stretching it into a key, but for people who use a decent password this would be fairly secure.

>However, that's not what his views are!

I'm not sure how you got to that conclusion. Certainly I don't see how

>projects are better credentials than even degrees.

would necessarily conflict with

>that projects and learning do have fun elements attached to them and might not necessarily be part of a larger goal.

>might not necessarily have any capitalistic value attached to it.

You seem to use goals and "capitalistic value" interchangeably, I would just like to add that projects in people's portfolios are often not initially created to make money, but simply to satisfy the creator's curiosity or because they thought it would be neat.

Zeroing memory is probably already really fast compared to other things the system is doing. Something that happened to me a couple years ago: I was writing a benchmark that needed a lot of memory. I just used a vector<char> for that. Of course, the vector zeroes the memory, so I thought hey, I don't actually need it to be zeroed, so why not just use unique_ptr<char[]>? Well it turns out (and most people here probably know what's coming next) that when you reserve memory, you don't actually get any physical pages. They get reserved as you access them. And since apparently the access pattern was worse (or something to that effect), the benchmark ended up running way slower than it did without explicit zeroing, even if I put the zeroing into the benchmark which it hadn't been previously. It turns out compared to reserving memory, zeroing was essentially inconsequential. So I'm not too optimistic that there are a lot of gains to be had here.

>Those subjects require a different sort of motivation than a motivation

Is that really the case? Apart from the obvious "maybe that's what they're intrinsically interested in" - if you start with a problem, try to solve it, and "pure mathematics" (whatever exactly that is supposed to be, anyway) is required to arrive at a solution, it becomes part of the intrinsic motivation. And if you keep solving problems without it the question that eventually comes up is "is it really useful at that point?"

I do however agree that if you're looking at someone who's qualification is primarily his "portfolio", you do actually need to check whether it includes interesting problems, or at least projects that are related to what you need them to do at your company. But if that is the case, I really don't see a problem.

If the secure enclave implements the time lockout (well, supposedly I guess considering it seems broken) then the device is indeed a game changer, thanks for that information!

That's exactly what I mean - the usual key complexity rules apply, and have always applied.

Shouldn't you always be able to completely bypass that by taking out the chip or something and just probing it directly? I guess that might be a bit much for normal police work, but in terms of "can the government (read: NSA) get into this" this doesn't really seem to change anything.

Hmm. I've only really played around with both (OpenGL 4.x and Vulkan), but while Vulkan had an insane amount of boilerplate initially, it was really intuitive to me. The situation of "what do I even have to google here?" never came up, while that happened a lot with OpenGL. If you already have a working code base obviously that doesn't really matter, but if I was writing a new engine today, I'd probably use Vulkan just because the API seems so much more intuitive to me. (Well, Vulkan or D3D11.)

So what's the deal with this? Isn't it just brute force? I would've expected the NSA to have something like that since iPhones first hit the market.

>Oddly, I find the most prestigious companies are the ones who care the least.

Hmm, I wonder about that actually. From what I've heard (hearsay, really), for a normal application Google and Microsoft won't look at it without a degree. But maybe they don't really look at it anyway. The only big company that I've heard doesn't really care is Nvidia, so props to them I suppose, but again, I heard that from one guy who's working there who might not have been entirely honest about prior contact with them, so I really can't say for sure. It would definitely be interesting though.

While there certainly are a lot of companies that don't care about your degree, there are at least as many companies that won't even look at your resume without one. It literally gets auto-filtered. (Especially with less than 5 years of experience.) And as much as I'd like to say that you don't want to work for those kinds of people anyway, in my experience it is at best loosely connected to how your day to day work life actually looks like.

>and maybe further explain if prompted.

I write manuals for computers.

"So, like, for how to use them?"

No, the computer reads it so it knows what to do.