Benjamin Hall
@Benjamin Hall
Best posts made by Benjamin Hall
-
RE: Asking for Passwords
@Benjamin-Hall I take it back. It's worse. They're using a google form to collect the passwords...
I quote from the email (and this was repeated in person):
Please fill in the Google form below with your full name and computer password.
Computer Password Request Form. You must sign in with your Tampa Prep email in order to be able to open the form.
Note: You will see a little warning message saying “Never submit passwords through Google Forms”- please ignore that message. -
RE: One final niggly detail
@cartman82 I'm no lawyer, but if you didn't sign it up front, it didn't happen. Their loss.
Latest posts made by Benjamin Hall
-
RE: Nope, you eat it
@dkf said in Nope, you eat it:
tuna pizza
The "Nope, you eat it" thread is... Oh wait. Carry on. But ewwwww!
-
RE: Nope, you eat it
@Arantor I guess it's better than trying to oxygenate water and ending up with H2O2.
-
RE: Today in reading the headlines...
@Zerosquare I did notice that there were order-dependent effects on test grading, but
- I didn't grade alphabetically but in order of receipt.
- The effects weren't always negative. In fact, I found myself naturally being harder on the first few until I settled into a rhythm. I then tried to go back and regrade the earlier, harsher ones to adjust.
So
-
RE: Nope, you eat it
@Arantor honestly, the extra H2 is just going to leave. Either diffusing through the walls of the container or instantly once the bottle is opened.
So yeah, pure placebo + actually drinking water.
-
RE: Today in reading the headlines...
@Arantor said in Today in reading the headlines...:
Golden Axe is, uh, less than detailed in its story.
And the only notable things in there are the beefcake character models in less than properly clothed conditions. Which I doubt will be allowed to continue in a show version.
-
RE: WTF Bites
@Tsaukpaetra said in WTF Bites:
@Benjamin-Hall said in WTF Bites:
But for UDP and sockets
That's the bizarre part for me. Once the UDP socket is "opened" it shouldn't be "re connecting" (things that don't make sense in UDP world), the socket connection itself maintains the state and IP address it's apparently connecting to.
Unless you're tearing down the object and recreating the socket for each packet....?
I'm not sure. All I know is what I observed, that each part of the login flow was getting a different IP that cycled between the 3 LB IPs.
I'll admit, the whole library we're using for this is a totally janky mess we inherited from our "R&D" partner. And since it's not the one we use for 99% of our workflows (ie actual clients, which are using variants in other languages since they're native to embedded systems, android and apple respectively), we don't do as much heavy validation on its behaviors.
-
RE: WTF Bites
WTF of my day (ok, one of them).
This is something I'd seen before, which was good. Because that meant that it only took me 45 minutes to diagnose the issue and provide a solution to my coworker whose ticket it was. But still.
We have a piece of software that makes some requests and opens a pair of UDP sockets. Those sockets are authenticated by a janky homegrown protocol (literally called the Janky Session Protocol). This relies on a HLO (hello) message that the server replies to with a hashed token. The client then sends back a LGN (login) with that same token and a salt agreed on earlier. If it matches, the session begins. But it has to match for the entire socket--if I HLO on ephemeral port A and LGN on ephemeral port B, that's a no-go.
The server has a CNAME DNS record pointed at a load balancer, which has 3 IPs backing it. Of course different connections could get any of those records depending on if they re-look-up the DNS entry each time or not.
All of this is setup and, while janky, mostly works.
Now the WTF.
On macs, the default DNS resolution in NodeJS is to do the lookup once and then cache it at the os level, meaning the client always gets the same remote IP and is happy for the duration of the connection.
On linux, the default DNS resolution in NodeJS is to do the lookup each and every time a connection attempt is made. Which makes some sense--that's why load balancers exist. But for UDP and sockets, this makes for bad things--it will always get a different IP for each part of the connection.
As a result, when we're testing the thing even dockerized, it will always succeed on our developer machines and always fail when run from a linux-based EC2 instance. With extremely unhelpful error messages. I didn't notice it until I actually did a
tcpdump
on the traffic and noticed that the remote IPs were changing (and thus the sockets weren't the same).And no, there's no toggle. You have to manually do the lookup and force the connection to use the same IP (basically override the DNS name and do the connection to a specific IP, resolved once manually before you start the socket.
-
RE: WTF Bites
@Gearhead Quick question, outside my expertise, I am not a database expert. When would replacing Oracle MySQL with MariaDB be a problem? My first reaction was stored procedures don't work right but there are column rules and others no? Thank you! -GH
I'm not actually sure in this particular case, other than that the installation and behavior is twitchy enough without trying to use an unsupported version of a key dependency.
-
RE: "I swear to you, I did exactly as you told me......"
@Polygeekery said in "I swear to you, I did exactly as you told me......":
Seriously, what the fuck is wrong with a pinhole and a tact switch on the PCB?
We had that, on a device that's impossible to reprovision from factory without opening it up and connecting via serial debug line.
We asked a customer to power cycle the bridge (unplug and plug back in). They instead managed to push the unmarked factory reset button.