Yes, you still have the option of manually activating a venv, and that makes sense if the amortized cost of that is lower than several instances of typing `uv run `. Though sometimes when working in one project with its venv activated, I end up needing to run a tool from another project with a separate vent, so uv still ends up being useful.
Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn’t know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn’t ever seem to work right.
Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place. It seemed to work, given the limited “testing” that Fred did, but that was just a coincidence. Buoyed by false confidence, Fred charged ahead into oblivion. Now, most intelligent people may know someone like Fred, but we know better. We don’t rely on coincidences—do we?
Sometimes we might. Sometimes it can be pretty easy to confuse a happy coincidence with a purposeful plan
That's perfect! I program by coincidence all the time. The very definition of a hacker... "it works, I must have done it right". And if it doesn't work, keep adding more console.println statements until you find something unexpected, then add a "x = x" to fix it and BOOM I just wrote Snapchat give me lots of money.
I'm joking, but it hits a little close to home because all of us have done that before. You're at the end of your rope and just need this thing to fucking work and you'll deal with the "why" later. For now, x = x works dammit, and it doesn't matter why. Meanwhile the console is filling up with all of your variables being printed out because you couldn't figure out where the value of x was being corrupted.
The next morning you switch to functional programming and forget that day ever existed.
Ok so this allows them to unlock the car, maybe start it, though the article doesn't really get into that, but then what? After they drive beyond the range of the amplified key transceiver?
I can confirm that it doesn't shut off. At least in my case, it beeps for a while saying "KEY NOT DETECTED", but it doesn't seem to actually do anything about it.
When my key battery was low this would occasionally happen and it wouldn't actually do anything until you need to actually start the car again after stopping it.
09 Avalon uses same principle as in the article and is most likely vulnerable. Functionality that I have encountered:
Battery charged in fob:
Walk up to car push any button located on handle of doors to lock vehicle or push button on trunk to open trunk.
Within proximity to any door lights under side view mirror light up, interior lights also turn on. After touching driver handle driver door opens, any other door handle touched (within proximity to fob) will cause all doors to open.
Battery dead:
Trunk will open if fob is held directly near button.
Similar behavior on doors fob must almost be in hand pushing button. Valet key can open the driver door. Buttons to unlock etc dont work. Have to hold fob near push to start to start vehicle. Depending on proximity during drive the alert on dash may light up.
Few times I or S.O. has driven off without key (luckily realizing within a few miles of house or location of key). The Avalon will continue to run only having the alert on the dash. I'm guessing my defense here would be to let the batteries die in the fob. Ill still get most of the functionality without the risk. Keeping the battery one (when I want to sacrifice security for convenience) stored in a cage. Really like the attack though.
Every time I read this I am reminded of units(1) util, which is super useful and I always forget about and revert to Google. But yeah, that connect timeout to 500 mi correlation is fun too.
> In order to connect to known networks which don’t broadcast their presence, almost all your wifi-enabled devices: laptops, tablets, phones, etc. will try to probe for networks they know about
But aren't nearly all APs configured to broadcast SSID? So why is that probing necessary in general?
Some devices still probe, even for APs that broadcast their SSID. I honestly don't know enough about it to explain why, but I know some Android phones will probe (my Note used to, my nexus 5 doesn't)
How quickly did you read this? He says very nearly what you are saying:
"Well, I want to be a little careful here. I think it’s important to distinguish two areas where the word neural is currently being used.
One of them is in deep learning. And there, each “neuron” is really a cartoon. It’s a linear-weighted sum that’s passed through a nonlinearity. Anyone in electrical engineering would recognize those kinds of nonlinear systems. Calling that a neuron is clearly, at best, a shorthand. It’s really a cartoon. There is a procedure called logistic regression in statistics that dates from the 1950s, which had nothing to do with neurons but which is exactly the same little piece of architecture."
I'll just paste the same thing here that I wrote in response to commenters on FB misunderstanding the problem:
"Even though I disagree with most of your comments (to the extent that it is any more than unrelated editorializing) and everyone talking about "too many methods" etc, the actual bug that was triggered is here and provides a test case: https://code.google.com/p/android/issues/detail?id=22586 showing that multiple interface inheritance triggers this easily."
Issue 22586 - android - Dexopt fails with "LinearAlloc exceeded" for deep interface hierarchies
They do to a large degree yes. The Google maps add-on SDK for instance isn't available on devices that haven't been blessed by google (and received an official Vending.apk).
