invalidator

Maybe? I think they're mostly used as sports vehicles currently, but it might be possible to squeeze a more practical vehicle into that class.

Safety regulations.

"A Car" needs to be able to operate safely on highways at 60+ MPH. That means: horsepower, braking, crumple zones, airbags, crash testing, etc. By the time you add those up you've already exceeded that budget, and you only have a glorified rickshaw. People want doors, roll-down windows, etc, which all add cost... they're going to be better served with a used car in that price range.

The closest things that exist are Neighborhood Electric Vehicles. They're basically golf carts with seatbelts, allowed to operate on city streets up to 25 MPH.

It would be great if the US had something like Japan's Kei Cars. Those are $10k and up, fast and safe enough for local highway use (say 50MPH)... It works in Japan because urban traffic tends to be low speed. They are less practical in the US where freeways run through every city, but they'd still work for many people. They would require significant regulation changes.

You can! Get an energy-monitoring smart plug[1]. Set it up on Home Assistant[2] or another smart-stuff system. Then create an Automation which sends an alert when it drops below 25 watts for 3 minutes.

It's all-local, and requires no integration with the washer. 220V dryers may be a little trickier, but still easy enough if you're comfortable with basic electrical stuff. You can put a sensor on an indicator light, or put a current clamp on one of the wires. Usually you only care when the washer is done though, so you can move your clothes over.

[1] I use https://www.amazon.com/dp/B0BPY5D1KC for Zigbee, but there are WiFi/Z-wave/other options.

[2] https://www.home-assistant.io/

Reducing framerate doesn't help much when there isn't a lot changing between frames. Here are some better optimizations:

Noise reduction, so you compress less useless noise: -vf hqdn3d

Turn up the Constant Rate Factor. This will make better visual tradeoffs than decreasing frame rate. 23 is a good starting point for h264, but keep increasing it until you don't like how the content looks: -crf 23

Throw more CPU at the problem: -preset veryslow

Here a few options for you:

https://www.adafruit.com/product/2264 - USB to GPIO (and other stuff)

"Bus Pirate"

Or get a RasPi - it's not your desktop PC, but they're running Linux with direct GPIO access available in userspace.

Classic parallel (ATA, PCI, parallel ports) is going away and not really coming back. The newer interfaces like 4xPCIe and USB are multiple serial interfaces bonded together.

The difference is all the bits in a true parallel interface operate synchronously. All the bits get set; the clock pulses to signal data is ready; all the bits update again. The problem with this approach is you have to wait for all the bits to settle before you can read. It's no problem at low frequencies, but when you get into hundreds of MHz or more, it becomes a real challenge to get everything time-aligned.

4xPCIe channels operate on 4 independent clocks. They have the same nominal rate, but they don't have to be precisely aligned. Each channel is transmitting a single frame at a time - it's not splitting them into 4-bit packets and sending 1 bit down each channel.

I'm hard-pressed to think of a new technology in the last decade that implements splitting a byte into bits and sending each down a separate line.

Subcompacts sold today are much larger and heavier than what they used to be. Here are the lightest cars I could find for sale in North America in 2024 in 15 minutes of searching:

  Honda Fit    1,070–1,280 kg (2,359–2,822 lb)
  Mazda Miata        1,058 kg (2,332 lb)
  Mitsubishi Mirage    955 kg (2,106 lb)

Many of the old standbys (Scion, Fiat 500, Mini, etc) have disappeared, or gone electric (which is fine, but they're quite heavy).

Safety standards have driven a lot of that. Air bags, impact beams, high hood line for pedestrian safety, rollover protection, ABS, etc all add weight, which disproportionately impacts small cars. An SUV with a V8 doesn't care, but it's a pretty significant thing to add a few hundred pounds to what used to be a 1500 lb subcompact. It requires a bigger engine to keep performance acceptable, and now you need bigger brakes for the extra power, a better suspension for the higher center of mass, and it all just snowballs.

And that's where consumer choice comes in: people look at a "subcompact", and find that they're heavy, inefficient, and expensive, which are exactly the opposite of what they want in a subcompact car. Once you've already made those concessions, you might as well buy something bigger.

They're not telling us, so I'm assuming what's required for a very small, efficient car. It could easily be 50-100% more than that.

1km/s on a 1000km pack is a 3.6C charge rate. That's fast but not jaw dropping. Guessing it's a 100kWh pack, that's a 360kW charge rate, which is somewhat more than the 250kW Superchargers currently supply.

I think the real news is they're making a serious effort at large LFP packs.

I create wrapper scripts. I try to keep them simple... they're convenience scripts, not a replacement for a build system.

Here's one for a QEMU dev env where I add and remove bits of command line in a freeform way. I just break out the command line into components, and uncomment the ones I want for a particular use:

  #!/bin/bash
  
  set -ex
  
  # Drive created with:
  # /usr/bin/qemu-img create -f qcow2  ngx.qcow2 40G
  
  #vga='-vga cirrus'
  vga='-vga std'
  #vga='-vga qxl'
  
  drive='-drive file=ngx.qcow2,cache=writeback'
  
  tablet='-usbdevice tablet'
  
  #vnc='-vnc :3'
  
  #cdrom="-cdrom base_install.iso"
  #cdrom='-cdrom documentation.iso'
  #cdrom="-cdrom /dev/sr0"
  cdrom=''
  
  #net='-net user -net nic'
  net='-net user,restrict=off,hostfwd=tcp::6666-:6666 -net nic,model=rtl8139,macaddr=00:11:82:C3:54:55'
  #net='-net user,restrict=on,hostfwd=tcp::6666-:6666,hostfwd=tcp::3389-:3389,hostfwd=udp::3389-:3389 -net nic,model=rtl8139,macaddr=00:11:82:C3:54:55'
  
  monitor='-monitor stdio'
  
  qemu-system-x86_64 -enable-kvm -nodefaults -m 768 $vga $drive $tablet $vnc $cdrom $net $monitor

If you have multiple stages to your build/run process, you can chain together a few scripts. build-and-run.sh builds it, and then calls run.sh which runs it. If you want to skip the build step, you use run.sh.

Can you post an example of how you'd phrase the question to ChatGPT?

Mine consistently produces better rice than my old mechanical one. It's also slower. I think it does a more gentle temperature ramp than the mechanical one did.

Mars Pathfinder did exactly this. It was a tetrahedron which could land in any orientation. As it happened they rolled a 4, but if it was on one of the other 3 sides it would have pushed itself upright as the sides folded open.

https://en.wikipedia.org/wiki/Mars_Pathfinder

Yep! About 15 years ago I decided I didn't like what alcohol did to people around me and I haven't had a drink since.

headline.append(" Per File")

Ben over at Applied Science did a great video of his quest to build an analog bite sensor for a musician. It would be easy to adapt it to work as a TIG controller.

https://www.youtube.com/watch?v=ag_p8gayrTs

It's a piece of cake. BLE doesn't try to hide anything. Install "nRF Connect" on a mobile device and have fun.

My personal peeve:

  $ git log directory --stat
  fatal: option '--stat' must come before non-option arguments

Come on, Git, you know what I want. Just do it without making me repeatedly edit the middle of the command.

FFTW [1] does something like this, not just for parallelism but also for selecting optimal algorithms for a given data set and architecture. It uses "wisdom" to store known-good combinations, falling back on quick heuristics and brief benchmarking when needed. If you're going to do a lot of something you can have it update the wisdom from full benchmarks.

[1] https://www.fftw.org/

Something like this: https://www.amazon.com/dp/B007CZ6PD2

I just noticed that you're using a mains-powered pump, so don't splice its wires directly. Instead, insert the float switch on one of the wires between the QT Py and the relay.

I love ESPHome. The declarative language makes it fun and easy to do so many little tasks like this. Used with Home Assistant it makes it easy to create graphs of everything. Do I NEED to know how much water my tree consumes? No, but I like seeing it anyway!

When controlling physical systems I try to limit the damage they can do with simple interlocks. For instance, the relay I added to control my central heat is in series with a conventional thermostat which is set for a few degrees above pleasant.

Likewise, you can splice a float switch in line with the pump's power cable, positioned so it will cut off power if the water level nears the top of the tree stand. This will prevent the flood when the software decides to rebel against you.

> Who is hitting their head (and on what) in this sentence? Clearly there are no such thing as soft cars when it comes to human skulls?

Pedestrians, struck by the vehicle. A typical hard pedestrian strike hits the legs, and the person flips over and hits their head on the hood. Modern vehicles ensure there is a significant gap between the hood and the engine, so the hood has room to deform and absorb the impact.

So yes, a large piece of thin sheet metal can be a relatively soft place for a skull to land.

You don't pull all of the control rods at the same time. You can fully withdraw some number of them, then control the reaction with a few more rods.

There are several strategies to provide additional control so it's not all at the bottom. For instance, in a PWR, reactivity decreases with temperature, so additional coolant can be injected where additional reactivity is needed. In the RBMK, a small number of rods were inserted from the bottom to provide more axial control.

I suggest adjusting your gradient so they don't fully fade out until just before the sweep hits them, or maybe even only down to 10%, so they only get wiped by the bar. It'll make it much easier to watch a plane if it doesn't keep disappearing entirely.

If the write-cache is reordering requests (and it does, that's the whole point), you can't guarantee that $milliseconds will be enough unless you stop all requests, wait $milliseconds, write your commit record, wait $milliseconds, then resume requests. This is essentially re-implementing write-barriers in an ad-hoc, buggy way which requires stalling requests even longer.

Flush+FUA requires the data to be stored to non-volatile media. Capacitor-backed RAM dumping to flash is non-volatile. When a drive knows it has enough capacitor-time to finish flushing all preceding writes from the cache, it can immediately say the flush was completed. This can all be handled on the device without the software having to make guesses at how long something has to be written before it's durable.

In my opinion, if you asked for --help, the help IS the program's output, and should go to STDOUT. Unsolicited help messages for incorrect command lines ought to go to STDERR.

It's especially frustrating for programs which only write to files or something, and never produce output on STDOUT.

As long as it hasn't achieved orbit, all the pieces will end up on an elliptical track with the lowest point inside the atmosphere. Some stuff might get flung way up, but it would still need another maneuver (requiring working engines) near the highest point to circularize the track to prevent it from coming back down.

There's not much ambiguity for when to destruct. It's just: has it gone far enough off course that it could free-fall outside the predetermined borders where it's acceptable to crash? Then it's time to blow it up so it doesn't fly any farther.

One of the niftiest ways I've seen this done was some software I used circa 2000 (I don't remember the name). It would create a variable-rate timelapse by saving a frame every time the image changed more than $x percent, calculated as the sum of differences of pixels from the previous frame, or thereabouts.

If someone was walking across the yard it would save every frame. The movement of the sun would move shadows enough to trigger a new image every few minutes. A bug flying past was small enough that it wouldn't trigger anything. The result was you could get a short video of everything interesting that happened through the day: shadows of trees sliding over the ground, every frame of the car pulling out of the driveway, shadows sliding over the ground some more, cat walks across the yard then lays down, shadows pan around more while the cat sits still, cat gets up and walks away, shadows pan around until the delivery guy comes...

It was an incredibly low-CPU way to see everything that happened without missing anything, and without having to fine-tune the motion detection very much. You just mask out any areas with constant motion, then adjust the slider for how much change triggered the next frame, which would let you adjust how fast the timelapse would go during the boring parts.

I've always wondered why the technique never became widespread.

Jalopnik is all about hyperbole and making fun of everything automotive. This is actually pretty mild for them. :)

I use a kinda hacky bit of JS to do a number of actions based on the current URL. I create bookmarks like this, and set a keyword (this one is 'gt', for Google Translate):

  javascript:location="https://translate.google.com/translate?hl=&sl=auto&tl=en&u="+location

On any page, I can type ctrl-L (select address bar), gs, enter, and I get the page translated to English.

A couple more:

  Wayback machine: javascript:location="https://archive.md/submit/?url="+location
  12 foot ladder: javascript:location="https://12ft.io/proxy?q="+location