litchralee

In the same way that torque/current-limited ebikes will cause less soil erosion in national parks -- case in point, Tahoe National Forest in California now explicitly permits Class 1 ebikes on trails, once they had enough data to support that assertion -- I would expect that an electric horse could also be tuned to limit its acceleration on tricky surfaces.

If time is of the essence, then wireless charging is even worse in comparison to wire conductors. Almost by definition, any stationary wireless charger laid into the ground is supplied by wires, so might as well have conductors all the way that are position-independent and free to use. A dangling USB C cable of any power capacity is going to be a more common standard for more people, while also being compatible with phones and other accessories.

Ok, but why wireless charging? The reason that wireless charging works for mobile phones but not automobiles is precisely one of efficiency: delivering only 60% of input power to a phone is fine because that's only a few Watt-hours of loss, but is definitely not fine when it takes 100 kWh to charge a 60 kWh electric car battery. The wastage is catastrophically not worth the convenience if not plugging the car in.

Why then would we want wireless charging for electric cargo bikes, as pictured? Even for normal electric bikes, a bike shelter with USB C cords dangling down from retracting reels would be far superior, and provides weather protection and locking options.

The lawsuit (which the article has included a link to!!!) claims that Specialized's website did not disclose certain fees (eg handling fee, battery disposal fee) prior to the checkout page, in violation of laws in both Virginia (where the plaintiff lives) and California (where Specialized is headquartered).

The suit was filed in the Northern District of California federal court, because: 1) a national class-action suit can only be filed in federal court, not state court, 2) both the lead plaintiff and Specialized reside in different (ie diversity) states, and 3) that court's geographic district includes Specialized, as the defendant, and also is the presumed location where their website was designed.

In the early 1900s, horses were the original "mobile emissions" source of pollution, causing great consternation to anyone that happened to be in their wake at the wrong time. Yes, we have troughs that catch horse poo now, but still doesn't perfectly mitigate the problem specific to horses.

And then there's the issue of horses on surfaces: on dirt, their weight cause erosion. On pavement, they can injure their hooves, plus the sound of horseshoes at full gallop on asphalt must be deafening.

(I promise this isn't a subtoot about automobile environmental impacts)

As an aside, in wilderness in America, where there is the most protection for the environment and anything mechanized (like bicycles) are prohibited, it is a bizarre historical exception that horse riding is permitted, in spite of the obvious degradation caused by trampling over everything. Wilderness is meant to be a nature-first place, but somehow it's actually horseriders-first, then nature.

Having spent much of my software engineering career training and mentoring interns, new-hires, and transfers from other departments, and having toiled with some of their truly inexplicable questions that reveal shaky technical foundations, I can understand why so-called AI would be appealing: inexhaustible, while commanding the full battery of information stores that I could throw at it.

And yet, the reason I don't use AI is precisely because those very interns, new-hires, and transfers invariably become first-class engineers that I have no problem referring to as my equals. It is my observation that I've become better at training these folks up with every passing year, and that means that if I were to instead spend my time using AI, I would lose out on even more talented soon-to-be colleagues.

I have only so much time of my mortal coil remaining, and if the dichotomy is between utilizing inordinate energy, memory, and compute for AI, or sharing my knowledge and skills to even just 2 people per year for the rest of my career, I'll happily choose the latter. In both circumstances, I will never own the product of their labor, and I don't really care to. What matters to me is that value is being created, and I know there is value in bringing up new software engineers into this field. Whereas the value of AI pales in comparison, if it's even a positive value at all.

If nothing else, the advent of AI has caused me to redouble my efforts, to level-up more engineers to the best of my ability. It is a human legacy that I can contribute to, and I intend to.

Did ATT specifically say that their modem will factory resets due to loss of power? Because that's genuinely unbelievable as a design feature for domestic-grade equipment. More reasonable would be that the modem will reboot when it encounters a brown-out condition, where the AC voltage briefly dips too low for the circuitry to continue operating.

A power strip with just an MOV circuit would only help if the problem was a brief spike in voltage. A power conditioner would only help if it's the shape of the AC voltage that needs to be cleaned up. That is to say, no dips or spikes, but rather the sinusoidal shape is messy due to other devices in the building.

A UPS (which almost always includes an MOV circuit and power conditioner) would switch to battery power whenever there's a problem with the AC voltage, so any momentary issues will be addressed. This switchover tends to happen within 2 cycles of the 60 Hz AC frequency, and that's generally good enough most home appliances. I'm guessing the modem has a switch-mode power supply, so even a cheap UPS with square/stepped wave output will work.

I too have issues with silicone earbuds, and also with them falling out. Which is why I was over the moon when I discovered wireless clip-on earbuds. They meet my criteria of being convenient (because wireless) while also not falling off (because clip-on). The specific ones I bought (Anker Soundcore c30i) are not noise-cancelling, but I found that I can adjust their position up or down my ears to meet conditions. For example, I wear them high up when out in public, to hear wayward automobiles that might run me down.

Please see my review of the Ninebot GL30P, here on c/micromobility, which I purchased after receiving advice from this community.

But my own sensibilities aside, it’s fairly capable with large – but still jarring – dips in the road surface, and does not bottom-out at sidewalk ramps or turning into driveways.

After 8 months of use, I can say that it has no issue with gentle slopes, although you may have to be in "drive" mode (the middle power mode), since "eco" (the lower power mode) is power and speed limited. I personally don't use "sport" mode, since the thing will take off very quickly, and that's too much of a handful for me.

Walking it off a typical curb, it doesn't bottom out. But with no suspension (by default; I'm informed this is a not-uncommon upgrade that can be made), the drop is very jarring, so I don't personally ride the scooter off a curb. But up or down a driveway cutout, it's very smooth and I do that regularly.

Fair, though I personally don't let my ISP indirectly dictate what I do with my LAN. If I didn't already have a v6-enabled WAN, I would still manage my LAN using IPv6 private range addresses. There are too many benefits to me, like having VMs and containers be first-class citizens on my LAN, rather than sitting behind yet another layer of NAT. That lets me avoid port forwarding at the border of my home Kubernetes cluster (or formerly, my Docker Swarm), and it means my DNS names correctly resolve to a valid IP address that's usable anywhere on my network (because no NAT when inside the LAN).

I will admit that NAT64 is kinda a drag to access v4-only resources like GitHub, but that's only necessary because they've not lit up support for v6 (despite other parts of their site supporting v6).

This is my idea of being future-ready: when the future comes, I'm already there.

The approach isn't invalid, but seeing as you already have the framework set up to deny all and log for IPv4, the same could be done with IPv6.

That is to say, your router advertises an IPv6 gateway to the global internet, but you then reject it because your VPN doesn't support v6 (sadly). I specifically say reject, rather than drop, because you want that ICMP Unreachable (administratively prohibited) message to get returned to any app trying to use v6. That way, Happy Eyeballs will gracefully and quickly fall back to v6.

This makes your apps able to use v6, for that day when your VPN supports it, and so it's just a question of when the network itself can be upgraded. IMO, apps should always try for v6 first and the network (if it can't support it) will affirmatively reply that it can't, and then apps will gracefully fall back.

This also benefits you by logging all attempted v6 traffic, to know how much of your stuff is actually v6-capable. And more data is always nice to have.

I'm so confused on what the point of such a hash would be. If the time that an email was sent was so important, would existing DKIM timestamps also work? Is this basically the digital equivalent of including today's newspaper in a ransom note?

Not to say that DKIM as-used is perfect.