Self-control is not a "have it or don't" thing. It can be developed and exercised, often simply by trying and failing, and then trying again (like any exercise!).
I'm not saying it's not harder for some people than others. I'm also not saying that it isn't harder to exercise on some circumstances than others. However, it's absolutely not a binary thing, and it is achievable, in some form, for anyone.
It's also about building systems to help with self control. Turning alerts off would be one. Leaving the phone in another room for longer periods of time is another.
Probably because it's not actually a truthful characterization of what happened! I know it's popular to find every possible reason to bag on Musk, but you don't need to resort to disinformation to do it.
They didn't, and you're again repeating misinformation as fact.
What happened was that they refused to turn access on for the Crimean region, which is not the same as "cutting off Ukrainian access".
I understand nuance is hard to grasp sometimes, but if you're going to continue to conflate the two things, I can only chalk it up to a desire to deceive.
> And installing malware on the computers of people merely suspected of a crime is even more insane.
But it's not "merely suspected"! It's "suspected with enough evidence to convince a judge to issue the warrant". These are completely different things, and to intentionally confound the two is wildly disingenuous.
I don't see how that's much better; a judge is just one guy and he's only hearing the cops' side of the story since you aren't allowed to know you've been accused, let alone present your side of the story.
I mean... yes, that's how police surveillance works? People don't want to do illegal things when they know the police is watching, so sometimes the police has to spy on people before they can prove they did something illegal. The person being spied on can't present their side of the story, because if you tell them they're being investigated, they'll just lay low.
So yeah, there's always the possibility that the cops spy on someone innocent or try to dig up dirt on a journalist or something, and that's why warrants exist. If you don't think a judge's oversight is enough for the police to intrude on someone's privacy, then you're basically saying that the police should only ever have access to OSINT sources and nothing more.
Anyone, by that I mean anyone that matters, or a very large group of people that you should be afraid of to have this power. I mean, excuse my hyperbole, but is this not enough?
I think he didn’t mean that say “everyone” but rather “anyone who is some random person working for this private company or the cops or the government or whoever they inevitably sell this data to/gets access to the data when it inevitably leaks through some random unsecured s3 bucket”
Submit a FOIA for a specific area and time, and you can get all of the raw data for that, then you can do your own searches. You generally cannot submit a FOIA for all of the data.
The reason I'm skeptical of this, in this particular case, is because the data here isn't actually owned by the police/government (I think?), it's owned by Flock. A department can search the data for given attributes, but I don't think they have the whole data set to provide as a response to a FOIA request in the first place.
I don't have a source on hand but I do remember seeing a recent case on this stuff that indicated that "even if they're paying Flock to store it, it's still the government's data"
> On a related note, when I lived in FL, I often saw cars with this opaque plastic cover on number plates. I think these are installed by the drivers so that they can avoid paying road toll (FL has many road tolls). I also noticed that these drivers tend to be more aggressive in driving than others (that's how I noticed their license plates are covered).
I've noticed the same thing in my area of CA. Lots of folks with different devices to obscure their plates, and a strong correlation between the obscured plates and very poor or aggressive driving.
I've started to quip that the obscured plates + tinted windows + blacked-out taillights is the "frequent moving violation starter kit".
Or "tell me you violate the rules of the road without telling me you violate the rules of the road".
> Will the same punishment be applied to those drivers?
One could imagine that's actually the targeted demographic, and not the subset of folks trying to circumvent Flock cameras.
I think flock tracks more than just the number. A plate cover is another piece of entropy that can be used just like browser fingerprinting. The tinfoil hat side of me thinks the camera aspect is a red herring and they are actually using the tire pressure sensors and other junk to do the actual tracking.
I mean, is it a problem if that's what I believe? In practice I'm not even getting "tracked". No one is likely to be looking up my license plate and looking at my movements, because I don't do anything that would warrant that kind of attention.
In the off chance someone is looking up that information, it's probably a mistake (i.e. mistaken identity), and seeing where I've been will likely clear that up.
And in the infinitesimal chance it doesn't, I imagine motive would be really hard to establish.
I'm not saying we shouldn't have proper oversight, strong data controls, etc, but I'm not opposed to this kind of tracking on principal alone. It does have real benefits!
But personally, seeing and meeting the kinds of people who oppose this kind of tracking _on principal alone_, I'm immediately suspicious of all of them. But that's definitely bias on my part: I've known many folks in this category from the world of crypto, and 90+% of them are just trying to avoid taxes and/or scrutiny of accountability for whatever scam they're running.
> No one is likely to be looking up my license plate and looking at my movements, because I don't do anything that would warrant that kind of attention.
Want to spend an hour on the side of the highway while the police search your vehicle?
> Want to spend an hour on the side of the highway while the police search your vehicle?
Again. I don't commit crimes, so this isn't likely to happen to me. And if it does, they will find nothing, and I'll be slightly inconvenienced. It'll suck, but you know what else is inconvenient? Getting bipped.
Guess which of those risks is higher, and which has changed more based on this technology?
> The principle is _Don't Tread On Me._
Pretty sure that doesn't mean what you think it means. Tracking your movements in public spaces doesn't diminish your freedom in any way, so nothing is being tread on.
> No one is likely to be looking up my license plate and looking at my movements, because I don't do anything that would warrant that kind of attention.
What makes you so incredibly sure that you will never in your lifetime do a single thing that would ever draw this kind of attention, no matter who is pulling the levers of power?
I live in a country where such abuses are rare? They happen, sure, and are broadly covered when they do, but this distorts the perception of how often they happen, which is "not very often".
I also don't commit crimes, so I really don't have much to worry about.
This, coupled with the fact that I will leave the country if abuses start to become more common, gives me a lot of confidence that I indeed have nothing to worry about.
And I like the decreases in crime that these kinds of technologies drive. The downside of them can be large, sure, but the downside risk is minimal. The upside is small to medium, but is real and demonstrable.
To me, that makes it worth it, and I tire of folks who would prevent the upsides of various technologies, based on hypotheticals, vanishingly unlikely scenarios, and their own downside risks--which might, as it turns out, be large because they're the ones committing crimes?
> This, coupled with the fact that I will leave the country if abuses start to become more common, gives me a lot of confidence that I indeed have nothing to worry about.
There's a lot about your post that seemed naive, but this one takes the cake.
Given how we treat immigrants in the US, and the wave of anti-immigrant sentiment that seems to be rising throughout the world, what makes you think the world would actually want you in their country?
Out of curiosity, why are such high fps numbers desirable? Maybe I don't understand how displays work, but how does having fps > refresh rate work? Aren't many of those frames just wasted?
If you have a 60Hz display and the game is locked to 60fps, when you take an action it may take up to 16.67 milliseconds for that action to register. If the game is running at 500fps, it registers within 2 milliseconds, even though you won't see the action for up to 16.67 milliseconds later. At extremely high levels of competition, this matters.
> even though you won't see the action for up to 16.67 milliseconds later
Note that this is only the case if you have vsync enabled. Without vsync you will see the action (or some reaction anyway) +2ms later instead of +16.67ms, just not the full frame. This will manifest as screen tearing though if the screen changes are big - though it is up to personal preference if it bothers you or not.
Personally i always disable vsync even my high refresh rate monitor as i like having the fastest feedback possible (i do not even run a desktop compositor because of that) and i do not mind screen tearing (though tearing is much less visible with a high refresh monitor than a 60Hz one).
> If the game is running at 500fps, it registers within 2 milliseconds, even though you won't see the action for up to 16.67 milliseconds later.
Okay I think I follow this, but I think I'd frame it a little differently. I guess it makes more sense to me if I think about your statement as "the frame I'm seeing is only 2ms old, instead of 16.67ms old". I'm still not seeing the action for 16.67ms since the last frame I saw, but I'm seeing a frame that was produced _much_ more recently than 16.67ms ago.
This is mostly like high fidelity audio equipment, or extreme coffee preparation. Waste of time for most people.
I used to play CS:Go at a pretty high level (MGE - LE depending on free time), putting me in the top 10%. Same with Overwatch.
Most of the time you're not dying in a clutch both pulling the trigger situation. You missed, they didn't, is what usually happens.
I never bothered with any of that stuff, it doesn't make a meaningful difference unless you're a top 1%.
But there's a huge number of people who play these games who THINK it does. The reason they're losing isn't because of 2ms command registrations, it's because they made a mistake and want to blame something else.
I'm sure that's true, but low latency can just plain feel good. I don't play FPSses at all, and I can totally understand how low latency helps the feeling of being in control. Chasing high refresh rates and low latency seems a lot more reasonable to me than chasing high resolution.
That's correct, and the most competitive multiplayer games tend to have fixed tick rates on the server, but the higher FPS is still beneficial (again, theoretically for all but the highest level of competition) because your client side inputs are sampled more frequently and your rendered frames are at most a couple ms old.
I think you're missing the point. The game could be processing input and doing a state update at 1000Hz, while still rendering a mere 60fps. There doesn't have to be any correlation whatsoever between frame rate and input processing. Furthermore, this would actually have less latency because there won't be a pipeline of frame buffers being worked on.
Tying the input loop to the render loop is a totally arbitrary decision that the game industry is needlessly perpetuating.
No, I'm explaining how most games work in practice.
You're right a game could be made that works that way. I'm not aware of one, but I don't have exhaustive knowledge and it wouldn't surprise me if examples exist, but that was not the question.
I would not at all be surprised that there are examples out there, although I don't know of them. Tying the game state to the render loop is decision made very deep in the game engine, so you'd have to do extensive modifications to change any of the mainstream engines to do something else. Not worth the effort.
But a greenfield code shouldn't be perpetuating this mistake.
On most modern engines there is already a fixed-step that runs at a fixed speed to make physics calculation deterministic, so this independence is possible.
However, while it is technically possible to run the state updates at a higher frequency, this isn't done in practice because the rendering part wouldn't be able to consume that extra precision anyway.
That's mainly because the game state kinda needs to remain locked while: 1) Rendering a frame to avoid visual artifacts (eg: the character and its weapon are rendered at different places because the weapon started rendering after a state change), or even crashes (due to reading partially modified data); 2) while fixed step physics updates are being applied and 3) if there's any kind of work in different threads (common in high FPS games).
You could technically copy the game-state functional-style when it needs to be used, but the benefits would be minimal: input/state changes are extremely fast compared to anything else. Doing this "too early" can even cause input lag. So the simple solution is just to do state change it at the beginning of the while loop, at the last possible moment before this data is processed.
Source: worked professionally with games in a past life and been in a lot of those discussions!
I can give an example. I'd heard that Super Meat Boy was hard, and it was, but it turned out, if you ran it at the 60hz it was designed for instead of 75hz, it was considerably easier. At 120hz it was unplayable.
You kind of understand how the game loop is tied to the refresh rate in games like this, though. Practicing "pixel perfect" jumps must be challenging if the engine updates aren't necessarily in sync with what goes on on screen. And in the really old days (when platformers were invented!) there was no real alternative to having the engine in sync with the screen.
In the model I am describing there would be whole game state updates on every tick cycle, completely decoupling the frame rate from the response latency and prediction steps.
Doing that will increase input latency, not decrease it.
There are many tick rates that happen at the same time in a game, but generally grabbing the latest input at the last possible moment before updating the camera position/rotation is the best way to reduce latency.
It doesn't matter if you're processing input at 1000hz if the rendered output is going to have 16ms of latency embedded in it. If you can render the game in 1ms then the image generated has 1ms of latency embedded in to it.
In a magical ideal world if you know how long a frame is going to take to render, you could schedule it to execute at a specific time to minimise input latency, but it introduces a lot of other problems like both being very vulnerable to jitter and also software scheduling is jittery.
Game has to process the input, but it also has to update the "world" (which might also involve separate processing like physics) and then also render it both visually and audio. With network and server updates in-between things get even more complex. Input to screen lag and latency is a hardcore topic. I've been diving into that on and off for the past few years. One thing that would be really sweet of hardware/OS/driver guys would be an info when the frame was displayed. There's no such thing yet available to my knowledge.
It doesn't and well programmed games won't be tied to fps that way. I'm not sure anything past 300 fps plausibly matters for overwatch even with the best monitor available.
You want your minimum FPS to be your refresh rate. You won't notice when you're over it, but you likely will if you go below it.
In Counter-Strike, smoke grenades used to (and still do, to an extent) dip your FPS into a slideshow. You want to ensure your opponent can't exploit these things.
Not OP but got quite a bit of experience with this playing competitive FPS for a decade. You're right that refresh rate sets the physical truth of it, e.g. 180 FPS on a 160 Hz monitor won't give you much advantage over 160 FPS if at all. However reaching full multiples of your refresh rate in FPS – 320 in this instance, 480, and so on – will, and not only in theory but you'll feel it subjectively too. I get ~500-600 FPS in counter-strike and I have my FPS capped to 480 to get the most of my current hardware (160 Hz). Getting a 240 Hz monitor would make it smoother. Upgrading the PC to get more multiples would also.
To certain extent for online games it can be advantage (atleast it feels like it to me). AFAIK The server updates state between players at some (tick) rate when you have FPS above tick rate then the game interpolates between the states. The issue is that frames and networking might not be constantly synced so you are juggling between fps, screen refresh rate, ping and tick rate. In other words more frames you have higher the chance you will "get lucky" with latency of the game.
If you're not using V-sync, if a new frame is rendered while the previous one wasn't fully displayed yet, it gets swapped to the fresher one half-way through. This causes ugly screen tearing, but makes the game more responsive. You won't see the whole screen update at once, but like 1/5th of it will react instantly.
I used to do that until I switched to Wayland which forces vsync. It felt so unresponsive that I bought a 165hz display as a solution to that.
>
Out of curiosity, why are such high fps numbers desirable? Maybe I don't understand how displays work, but how does having fps > refresh rate work? Aren't many of those frames just wasted?
I just quote the central relevant sentences of this section:
"For frames that are completed much faster than interval between refreshes, it is possible to replace a back buffers' frames with newer iterations multiple times before copying. This means frames may be written to the back buffer that are never used at all before being overwritten by successive frames."
Tying the input and simulation rates to the screen refresh rate is an old "best practice" that is still used in some games. In fact, a long time ago it was even an actual good practice.
I think it was just to show that the performance is comparable to Windows, implying that it also will be fine for games/settings where fps is in the range that does matter.
osu (music beat-clicking game) has a built-in screen frequency a/b test, and despite running on a 60hz screen I can reliably pass that test up to 240hz. It's not just having 60 frames ready per second, it's what's in those frames.
I don't understand how this works, I guess? If your screen is 60Hz, you're drawing four frames for every one that ends up getting displayed. You won't even see the other three, right? If you can't see the frames, what difference does what's in them make?
[E] Answered my own question elsewhere: the difference is the "freshness" of the frame. Higher frame rates mean the frame you do end up seeing was produced more recently than the last frame you actually saw
I think they're saying that learning to play golf is necessary to succeed in such an environment. I don't think they're claiming that learning to play golf is sufficient to succeed.
You're arguing against a point they weren't making, I think
So why are you making claims predicated on having knowledge of the situation?