I dunno about this - I leave my crossclimate 2 aw's on year round and they're pretty fantastic in snow. We had a pretty good winter this year (44" from dec-feb) and they just worked. I didn't go meandering around any mountains on them, mind you, but they're so far ahead of most typical all-season tires it's almost not fair to compare. For -most- lazy people who don't want to swap tires or rims, they seem a better option than leaving true winter tires on year round. Obviously, there are exceptions depending on where you live.
I've got two sets of wheels, and I rotate my tires every oil change, so it's not laziness that's the motivation. Instead, it was that with 2 sets of tires after 7 years of driving both sets still had tons of tread left but were starting to dry rot. I put about 60k miles on the car during those 7 years. So if I can get ~30k miles out of a single set of snows, and use them up within 5 years, that would be a much better use of resources. The cost isn't really a factor either, I just hate wasting stuff.
I've currently got something like 15k mi on the tires and 2.5yr of year round use. They appear to be wearing evenly and normally.
I agree, I have the same problem, that's why I'm sticking with the crossclimates year round also -- we only drive about 5,000 miles per year, so my tires die from age well before they would wear out from mileage.
I assume we're both making approximately the same optimization but you're going for better snow & ice performance at the expense of some summer and wet stopping distance, and neither tradeoff seems obviously wrong depending on our driving situations.
Yeah I would prefer to run something with an actual tread wear rating, as I believe it would spew less microplastic crap into the environment, and I suspect I might pick up 1-2mpg (maybe 5-7% better?) fuel economy with a less aggressive tire. But the winter performance is really important for me, especially on this car which is my winter beater/mile maker--for now, until it dies and donates its engine to a greater cause. The winters here (northern New England, IECC climate zone 6) are just about as extreme as it gets in the lower 48. The snow tires have the added benefit of being good in mud season. There are lots of dirt roads around here, it helps to be able to drive them without getting bogged in the spring.
Trying to jam in the extra characters for "efficiency" also doesn't really do much. Base84 is 6.4 bits per character, base64 is a flat 6 bits per character, base58 is 5.86 bits per character. It may intuitively feel like having 26 more characters to encode with would be hugely more efficient but for the extra risk of what all those characters get us we're only getting just over .5 more bits per character. I need to be either pretty desperate for efficiency, rare in 2026, or very, very sure that those things are only going places where those characters aren't risky or inconvenient, which is pretty difficult to guarantee since even if it is in fact true today who's to say it will be tomorrow, for this to be worth the risk of the extra characters.
Even just the extra characters in base64 are often annoying and we already have multiple common base64 standards because even trying to find just two more characters to fill out a-zA-Z0-9 is hard.
> Trying to jam in the extra characters for "efficiency" also doesn't really do much. Base84 is 6.4 bits per character, base64 is a flat 6 bits per character, base58 is 5.86 bits per character.
Also on efficiency, you are trading off code complexity for a little extra storage: base64 is a nice round 6 bits per character meaning every three bytes encoded is four output. Neither base84 nor base58 align on convenient bit boundaries like that so choosing the output character is more faf. Padding could be more complicated too.
Now if you are looking at a per-character limit where the characters are multi-byte (say SSMS shortcuts which are limited to 32767 UCS2 characters) then some form of base4096 (12 bits per character so three 8-bit bytes to two output characters) might be useful. Yes, I have done this: putting a long analysis proc (a replacement for sp_help & friends) into a “shortcut” I was getting close to the 32K-char limit so compressed and base64ed the code and included an unpacker. This was more than enough to deal with the problem (TBH, just stripping comments would have done!) and simplified things in some ways as I no longer needed to escape quotes and such, but I went one step further played with writing a B4096 encoder because I like playing with that sort of silliness. I went with 4096 due to aligning nicely with 4-bit boundaries, and finding 4096 useable characters (avoiding control characters, undefined codes, and other unprintables) is easy. If the limit is actually 32767 or any Unicode characters (including those not in the UCS2 or UTF16 base plane set) then you could perhaps get even more daft though I'm pretty sure it is just 16-bit characters and not full Unicode.
For efficiency, I would prefer to store files with a random short filename that's just letters and digits and store the original name in a separate database.
But with most houses, the AC will cycle on and off throughout the day anyway - raising the temp while you're gone will often result in less cycling. Especially if you also increase the hysteresis range while out. So you get a triple efficiency win, from better AC efficiency, less AC motor wear, and less heat loss to the outside.
On the brax thing - the "article" is a youtube video. There's a pretty reasonable amount of pushback here against video-only content where folks can't rip through quickly to figure out how relevant it is to them or if it's just a vapid ad.
Bandwidth is really cheap in bulk. You can get a 100 gigabit internet connection for about $10,000 a month. If you were to somehow keep that saturated 24/7, you'd move about 30 petabytes in a month, so your per gigabit cost is only $0.0003.
Realistically, if you had it 5% utilized, those million tokens would cost you about $0.0000062, which is pretty insignificant compared to what they charge you. (Assuming one byte per token, ignoring compression)
Most web devs have never heard of Colo unfortunately, they only know Vercel and AWS. Hurricane electric should sponsor more booths at colleges. If they give out more swag maybe the millenials and gen Zs would finally understand bandwidth pricing.
My friend's vibe coded vercel site got hit by Meta for 21 million page views in 2 days. It cost him over $300.
My self hosted compose stack running in my basement with two 9's of uptime was a 1 time cost of $600 between cat6e, refurb mini PCs and tons of time prompting for NixOS flakes that met my needs. I'm not sure who came out ahead.
It's not that I haven't heard of this, it's the reality that you have these constraints when you build applications on modern infrastructure. And let's face it, most of the applications use this infrastructure with these crazy prices for egress.
If you have a eufy scale, you can do this with no LLM needed - just set up an esp32 Bluetooth proxy, add it to home assistant, and then use the EufyLife integration someone already made. I did this recently with my scale to avoid having to sync it to my phone, go to the cloud, fetch data from the cloud, etc., and it's working fantastically. I have a little Home Assistant integration that pokes scale updates to a Python script running locally that provides a UI I like.
Huge fan of running it this way.
(Yesterday I ordered a more commercial, polished-looking esp32 Bluetooth proxy integrated into a smart plug - athome brand - but it's the same functionality, just in a nicer package than having a USB thing dangling from my outlet)
I actually found this out by accident. I set up a BT proxy to capture my combustion thermometers and saw eufy show up as an option and was like wait what? Honestly surprised how open it is.
I'm just using a cheap ESP-WROOM-32 but the recommended way to do it is with an wired ethernet-based ESP32 so you don't have interference with the wifi and btle. For a scale this works well enough. I haven't yet received the athom smart plug so I can't recommend it yet. Should be here in a week or so.
To setup the esphome bluetooth proxy you install esphome, and then create a yaml file that you'll use to configure the board, like this:
esphome:
name: bluetooth-proxy
esp32:
board: esp32dev
framework:
type: esp-idf
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "YOUR_KEY_HERE"
# Enable OTA updates
ota:
- platform: esphome
# WiFi configuration (matching the settings from your other devices)
wifi:
ssid: "YOUR_WIFI_SSID"
password: "YOUR_WIFI_PASSWORD"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Bluetooth Proxy Fallback"
password: "proxyfallback"
captive_portal:
# Enable ESP32 BLE Tracker
esp32_ble_tracker:
scan_parameters:
active: true
# Enable Bluetooth Proxy
bluetooth_proxy:
active: true
Once that's done, plug in your board to your system and use esphome run bluetooth-proxy.yaml (you might have to find the device it's showing up as in tty.usbserial or whatever).
Thanks so much, I appreciate the time you put into this comment. It is highly relevant to a project I’m currently working on, and has saved me at least a day of time.
I quite wish they'd move to terminal bench 4.0. 2.1 is saturated - there is no world in which Gemini 3.8 Flash is producing better code than Astra or Fable, as the 2.1 results might suggest. The 4.0 results differentiate these models much more effectively.
(2.1 is useful for knowing they can all one-shot straightforward scripts, of course.)
It does and that one also feels kind of saturated for measuring the most advanced models - opus, Gemini, astra, sol, fable, glm, kimi all scoring within statistical noise of each other. (74 +-3% down to 69% +-5% for kimi).
It's still providing strong discrimination between weaker models.
When I was in the final year of college in 04-05 my dream would be to work at IBM. It still had the kind of prestige of R&D in the world. Fast forward a couple of years to 08-09, I don’t recall the event but IBM perception went down and a stone. Was that when they sold the hardware business and became fully consultant?
I think they started on a long slide starting in the late 90s when they tried to couple research more and more tightly to product deliverables, and then as they pivoted to being a services company, including selling off non-mainframe hardware to Lenovo, to coupling r&d to, uh, I guess services revenue, whatever that means. They had some research layoffs in 2008, at the same time that MSR and Google were really blossoming in research spend and perception, and I think they kind of got left behind.
I had a former student go there around 2008 and it seemed like the vibes were starting to sour around then. They maintained some awesome researchers in, e.g., databases, but I think the "make sure you are showing closely how your research directly contributes to services revenue" thing was strong by then and somewhat ruinous for how pleasant a work experience it was for many.
Same. My first real job out of college was at IBM 2004 to 2005. I was so proud to be an IBMer. Hated it. Lots of good people, but the bureaucracy, the pace, the whole thing, not fun.
Alphabet is operating and expanding the only fleet of fully autonomous vehicles in the world, to rave reviews.
The first contact with AI most people have is Gemini. And their net income went from $74B to $100B to $132B in 3 years and profit margin from 24% to 32%.
Mediocrity and irrelevant are hardly how I would describe them.
You could interpret the comment as a prediction based on the same pattern of overwhelming internal bureaucracy impacting engineering innovation. Control swinging entirely over to finance and legal. Focused entirely on rent seeking and protecting monopolies.
reply