HN user

ReidZB

995 karma

I'm a site reliability engineer.

You can contact me at: hn [ at ] reidwiggins [ dot ] com

Posts1
Comments253
View on HN

Yes! OpenMW is amazing. I just did a full play-through without any issues and heavily modded to boot. Very stable, good performance, etc.

I also recommend this site:

https://modding-openmw.com/

for a good curated list of mods. It takes an age and a half to go through the installation of any of the lists, but the results have been very pleasant.

Wolfram Cloud 5 years ago

I find myself doing unit queries like 4 all the time. "80 bytes / second * 1 year" results in ~2.5 GB. Etc etc. It's very convenient for making sure that you're handling units correctly.

It's also really good for random facts. For example, "75 kWh at California electricity price". Or if you know something takes 20W to run continuously and you want to know how much it costs... "20 W * 1 year at california electricity price".

Wolfram Cloud 5 years ago

It really is amazing. I spent loads of time fiddling with Mathematica in college, thanks to the cheap(ish) student license. I solved problems 1 and 2 of the 'Substitute' xkcd ( https://xkcd.com/135/ ) using it, for example, including a little `Manipulate[]` bit that let you pick a starting run angle dynamically and plotted how far you'd get.

There's something really, really powerful about good interactive tools and learning math. I'm convinced my success in subjects like calculus and diff. eq. were driven by toying with programs like Mathematica.

Anyway, I still find myself reaching for it occasionally. I recently used Mathematica for some FFXIV raid group statistics. Once you get accustomed to it, it's incredible how productive you can be at solving specific problems. "Nuclear reactor included" is a great turn of phrase (from above).

I suppose eBPF could be used to implement real-time index updates, which could be neat. Maybe I'll investigate doing that as a little side project. Though from a quick look, doing it efficiently may require some modification to mlocate's updatedb program (depending on how -U works exactly...).

Yep! I've had two nasty bugs (intermittent audio dropping and HDMI CEC power off being broken) that were fixed by firmware updates.

I don't keep the firmware preemptively updated, though. I just did it as a debugging step in trying to fix some problems, and shockingly it did both times.

I have a couple modern LG 'smart' TVs that I don't connect to the internet, and they work just fine. As you say, they just display whatever is on the HDMI input.

I've updated their firmware a couple times. I connect them with wired cat6 on their own isolated VLAN to update, and then disconnect them afterwards. Maybe I am a little unnecessarily paranoid about it, but I don't really trust TV manufacturers, not with some of the (maybe apocryphal) stories I've read.

That's assuming you're varying only speed and not e.g. following distance. I try to leave at least 3 seconds' distance pretty much always (often more), so I have a pretty consistent amount of time to react regardless if I'm driving 30 mph or 55 mph.

Additionally, most of the metrics are cut-offs. It doesn't matter if you brake very gradually or if you brake very close to the area where it penalizes you. Based on my driving so far, the hard braking threshold is pretty forgiving. Yesterday, I let off the accelerator completely and went full-regen braking and it didn't care.

Anyway, I've driven 99 miles (highway/city mix) with the Safety Score thing turned on, and I'm still at score 100. I haven't slowed down at all.

I don't get it. The article clearly outlines the factors accounted in the safety score, and vehicle speed is not one of them (at least not directly). Yet the author and apparently others are intentionally driving slowly to boost their score? That doesn't make sense.

You can definitely "game" the score (to an extent) by making unnecessary trips, i.e. driving to give it more data, but driving abnormally slowly on those trips doesn't help anything. That is, unless you think driving 55 mph will help in the measures, but I'm skeptical of that.

The forward collision measure is based on number of miles, so if you drive 100 miles with no warnings, that's scored the same way if you were driving at 55 mph or 80 mph.

For the others (hard braking, aggressive turning, and unsafe following), each computes the percentage of time you spend doing the unsafe thing relative to doing it safely. If you want to improve those measures, you need to actually spend more time braking, or turning, or following at >50 mph and less than 3 seconds distance. Just driving a slow constant 55 mph on the highway won't change those measures at all, as I understand it.

The forced disengagement measure is just whether or not the car put you into autopilot jail for not paying attention while autopilot was active. I'd hope no one is getting put in that jail, but especially not if they're trying to be on their best behavior.

Anyway, from the Tesla FAQ, I find the 'predicted collisions in 1 million miles' formula fascinating:

    Predicted Collision Frequency (PCF) = 0.682854
      x 1.014495^{Forward Collision Warning per 1,000 Miles}
      x 1.127294^{Hard Braking}
      x 1.019630^{Aggressive Turning}
      x 1.001444^{Unsafe Following Time}
      x 1.317958^{Forced Autopilot Disengagement}
Hard braking and forced autopilot disengagement are, in their model, big predictors of a collision. I'm surprised to see unsafe following at such a low weight.

Being able to effectively reason about what the automation is doing is such an important part of why these technologies have been so successful in flight, and examples like this illustrate how far off we are to something like that in cars.

Is that actually the case, though?

I would hope, although perhaps I'm mistaken, that the developers of the actual self-driving systems would be able to effectively reason about what's happening. For example, would a senior dev on Tesla's FSD team look at the video from the article and have an immediate intuitive guess for why the car did what it did? Or better yet, know of an existing issue that triggered the wacky behavior?

Even if not, I'd hope that vehicle logs and metrics would be enough to shed light on the issue.

I don't think I've ever seen a true expert, with access to the full suite of analytic tools and log data, publish a full post-mortem of an issue like this. I'm certain these happen internally at companies, but given how competitive and hyper-secretive the industry is, the public at large never sees them.

For superchargers, where you'd want it most, no. Superchargers use a specific protocol to communicate with the car for purposes of billing -- tied to the Tesla account associated with the car. I don't think the plug itself is different than a normal Tesla plug (other than being beefier, perhaps?) but I could be wrong.

For normal Tesla wall chargers, like one that might be installed at someone's house, I think there are adapters that might work for the Leaf, but I have no experience with them.

That said, other than Tesla, I think there is standardization. Especially with Electrify America. But, Tesla's network is so convenient and widespread that it is currently a big selling point for the brand, in my opinion.

Definitely. Enmity between elves and dwarves is a deep theme in Tolkien's world. The Silmarillion presents several in-universe historical events responsible for that enmity. It's also foreshadowed by "God" (Eru) when he grants life to the dwarves.

Friendships between the elves and dwarves are as a result considered very special, which is why Gimli and Legolas's friendship in The Lord of the Rings is such a big deal.

Fun fact, that inscription also contains of the few continuity errors in published Tolkien material. It starts with:

The Doors of Durin, Lord of Moria

but as the Tolkien Gateway explains:

The name Moria means "Black Chasm" and was a derogatory description of the place which the Dwarves did not like, and was given after Durin's Bane took over the city in the Third Age. It is therefore a mystery why that name appears on an inscription made in the Second Age, and made in consent with the Dwarves.

The most common "mitigating explanation" I see is that Tolkien, the "translator," perhaps used the name the reader would be most familiar with (Moria) instead of the city's real name (Khazad-dûm) when transcribing the door's inscription.

Yes, it is arguably an unholy contrivance, but someone's already written it, and invoking it as a shell alias or likewise is both easy and useful.

    $ jq-structure my-file.json

Although it's about a different subject matter, I'm reminded of this quote from a patio11 article:

[A bank's] CS department is scored on number of tickets resolved per hour, and each rep’s incentives are simply to classify you as something requiring no followup and get you off the phone. [...] The legal department (or an analogous group – it is different at every bank) is not scored on cases resolved per week. They are scored on regulatory incidents per quarter, and their target for success is likely zero. Shockingly senior people will be involved to avert regulatory incidents.

src: https://www.kalzumeus.com/2017/09/09/identity-theft-credit-r...

Another huge difference: the current FSD feature set will not make turns at intersections as demonstrated in this video. It now (as of recently) can be configured to automatically stop at appropriate traffic signage (stop signs, red/yellow lights, not sure about yields). However, it won't make a left or right turn.

Some caveats: sometimes it will still want to stop at a green light, in my experience, and requires a manual override; and, if you're the foremost car in your lane at a traffic light, it won't begin moving on its own. I assume the same is true for stop signs.

I guess that video is intended to be a preview of what the current software could do with all the driver interaction safety switches off (no required hands on wheel, no requirement to confirm safety through intersections/turns, etc) and all the internal feature flags turned on (particularly: enabling turns and enabling Navigate on Autopilot on non-freeways).

Stack Sets are a killer feature, and so much easier than trying to do the same thing in Terraform.

CloudFormation Drift Detection is very limited currently: it only supports a small subset of resources that you can create with CloudFormation. If your needs are covered by it, great, but it doesn't take much to go beyond its bounds. Also, it detects drift, but won't correct it.

Terraform both detects and corrects drift on almost every resource, on every application. Sometimes there are limitations. This does result in extra work, as you can't just ignore drift without capturing that in code (via ignore_changes), but to me this is absolutely a desirable thing.

We use CloudFormation to actually create the state resources to store Terraform state.

Terraform can share outputs between different states using the terraform_remote_state data source, though there isn't any restriction on what can be done there (no requirement to update other stacks/states).

Despite being an AWS-only shop, we've found the multi-provider support in Terraform to be really useful. For example, as part of our environment configuration, we store resources in Consul, create Pingdom checks, etc all from the same set of Terraform code.

Drift detection is only implemented for a very small subset of resources: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

Terraform does indeed reconcile drift 'automatically' across all resources, by which I mean the plan will include changing everything that's drifted back to the specified configuration. That may not always be desirable, which is why building a good plan/apply process with approval is important. (Same goes for CloudFormation, though.)

That does not seem like a very generous interpretation.

I'd wager that most of Discord's clientele don't have any specific expectations for the word "server". Regardless, I think "server" was carried over from the Mumble / Ventrilo / Teamspeak gaming community.

I haven't used it or looked into what it supports, but I did remember this announcement which may interest you: "New – Port Forwarding Using AWS System Manager Session Manager": https://aws.amazon.com/blogs/aws/new-port-forwarding-using-a...

To make the ProxyCommand setup a little easier, perhaps you could use `aws ec2 describe-instances` with the appropriate filter? For example, the article I linked uses:

    INSTANCE_ID=$(aws ec2 describe-instances \
                   --filter "Name=tag:Name,Values=$INSTANCE_NAME" \
                   --query "Reservations[].Instances[?State.Name == 'running'].InstanceId[]" \
                   --output text)
to grab the instance ID from the Name tag. You could set up a shell script as a ProxyCommand to do this automatically, although beware that ProxyCommand's %h will always lowercase the input...

I'm not sure about what they've said in the past, but their site is pretty clear about the current state of Autopilot / Full Self Driving: https://www.tesla.com/model3/design#autopilot and for a more in-depth description: https://www.tesla.com/support/autopilot

Adaptive ("Traffic-aware") cruise control is actually an Autopilot feature, not FSD. Of course, Autopilot is a debatable name in itself, but Tesla does not market cruise control as FSD, at least not anymore. (I don't know if they ever did or not — honestly I didn't follow Tesla news until like 3 months ago.)

The closest thing to self-driving you get with the FSD package is "Navigate on Autopilot", which is something akin to "self-driving on highways only in good weather conditions". It can also drive around a parking lot on its own if you're supervising it, and it can supposedly park itself, though I've heard Autopark does not work well.

The HotSpot JVM may decide to stop building stack traces in some circumstances to improve performance (see the 'OmitStackTraceInFastThrow' option, enabled by default). Not sure about other languages / runtimes though.

That said, I agree exceptions should be reserved for exceptional circumstances. Something like checking if a record exists or not should probably use something like Optional instead, unless you are in a situation where a record "should" exist but doesn't (which is itself an exceptional case).

I've used Fastmail for many years now, and I have nothing but good things to say about the service. In particular, it's insane how well notifications work in Fastmail, especially compared to Gmail (which I use at work). (Honestly, you'd think Fastmail was the giant multi-billion-dollar super-advanced tech company, if you look at the quality of their email experience vs. Gmail.)

However, some folks are a little spooked by the privacy implications of it being ran out of Australia, so be sure to research that if you're interested in Fastmail.

Oh man, I have to disagree. I love the Ainulindalë. Plus, without it, I imagine you'd have a difficult time figuring out who exactly the Valar are or what their role is.

That said, my advice would be to not get too caught up on the names and places and details — just let the story sort of wash over you. Many, many, many names are only said exactly once in The Silmarillion; if you try to remember them all, you'll go crazy. If you see a name 3+ times, that's when it's time to track them down on the family tree, probably.

I'd also recommend making sure you reference the map when a place keeps being mentioned. It's helpful to know the vague locations of Doriath, Nargothrond, Gondolin, etc.

Oh, sure, maybe trivial isn't the best word for it, but it's all relative (to me). $20k is remarkably cheap for a practical cryptographic attack compared to the rest of the field, and there's plenty of software to do it, and it's been done before (many times).

Apparently there's even a SaaS offering to do it for you in some cases (for staggeringly cheap, like $300), but I had no idea that existed when I wrote my comment.

DES is a good example here: it was designed ~45 years ago and it's still theoretically surprisingly strong when you compare it with other areas of cryptography. By that, I mean it's held up very well to cryptanalysis that attempts to find faster-than-brute-force techniques, with the best attack taking 2^43 time (vs. the 2^56 brute-force time).

To be clear, 2^56 is trivially brute-force-able today, but that can be mitigated with constructs like 3DES, which are still (barely) secure despite being based on a 45-year-old cipher.

(So no one mistakes my intent, there are many reasons to prefer AES over DES. I just wanted to provide it as an example, especially since it happened to line up with the 40-year timeframe.)