I imagine it was what it felt like for miners when they went from working next to each other with pickaxes, to operating massive machines by themselves, although that timeline was much longer and less jarring, taking a generation or two.
"Many cars have an AUTO option now, but would you trust it to choose the right thing? I didn’t, being unsure if it properly accounted for daylight rain driving."
While it doesn't negate the iconography discussion throughout the rest of the article, the AUTO option is the intended default, because it turns on low beams in every case where they're needed, including daylight rain driving, which is based on the use of windshield wipers. I'm always a bit baffled at the modern cars driving around without their lights on. The car does it for you these days.
The ability to select low beams vs daylight running lights (DRLs) is mostly for convenience for one-off odd circumstances where you would want to override AUTO for whatever reason.
I think the problem is that AUTO behaves differently across cars. Some turn on the headlights when the wipers are running, others seem to rely mostly on ambient light
I have the same light control on my car. Here's how it gets turned off: when I'm parking with the engine off, waiting for someone, the lights stay on unless I turn them off manually. If I don't turn them off, my use of the stereo and other accessories ends sooner than necessary when the car shuts them off to preserve enough charge to restart the engine.
Then, when I leave, I forget to turn the lights back to AUTO. Now I have no lights at all except for the front DRLs. (Even then, though, the low beams still come on automatically when the wipers are turned on for more than a couple of cycles.)
Really, the OFF position should work only when the car is parked. Otherwise, it should be equivalent to AUTO.
My understanding is that the OFF position is for special cases, such as on ferries (the drive-on kind, obviously) where cars are densely packed and they can shine into the staff.
I imagine they're referring to the case where the ferry workers are directing you when you first drive onto the boat. Seems like a valid point, but I hardly ever take ferries and don't recall if there are signs asking drivers to turn off their lights.
It'd be best to simply remind the driver that the lights are manually turned off with a subtle notification in the display, and leave it up to the driver to decide whether they should remain off.
The problems with Amazon these days, which may or may not be related to a buyer's specific location:
- Shipping delays. Prime's biggest selling point, is useless if orders aren't shipped in the advertised Prime timeframe. I've quit my Prime subscription multiple times this year because this keeps happening.
- Excessive advertising/sponsored listings. Over half the listings in a search are now sponsored listings, which are often lower quality listings. And Amazon now puts unrelated banner ads next to listings.
- Returns. While returns are typically hassle-free, this leads to abuse of the system. The returns get put back on the "shelf" without much inspection, and there have been more than a few times where I got an item listed as New, which was very clearly Used.
And then there are the cases where someone returns an item, but puts something else in the box for weight, so you end up getting a completely different thing than you ordered.
I once ordered a parallel LiPo battery charging board, and in the box was a LiPo battery, which someone clearly put in the box for weight. That situation was particularly dangerous, because a LiPo, let alone a used LiPo of unknown charge state, cannot be shipped by air and must be shipped by ground. If Amazon had put that box on a plane, that'd be a serious safety issue.
A lot of the focus is the effect on pay, but some of the attention should also be spent on competence. There are individuals going through master's degree programs, which are essentially degree mills, to get hired at one of these (or similar) companies, who do not have the basic skills to do the job.
Not everyone, but a significant number, and if you've ever worked with one of these individuals, you know how demoralizing and frustrating it can be. Especially in the typical political climate in a tech company, where saying something even slightly related to immigration will get taken a certain way.
Yes, exactly. Without a hint of pettiness or subjectivity: To say that many of these individuals are bad at the job would be an understatement. They might as well be random non-English-speakers grabbed off the street and told "write a React app" or "administer this database" or "perform data analysis".
It's not their fault. But it's demeaning in the extreme to the experienced, dedicated natives who are forced to work with them.
I’ve experienced working with h1b workers that are not great, but this characterization is a bit rich. All of the massively valuable big tech companies have a ton of these workers. There’s no way they are like random people pulled off the street.
I haven't tried it as recently but last time I checked they only route once per session (or subagent). Imo this is basically impossible to do correctly. Consider the case where you start with one prompt "rewrite this in rust". Trivial in a 1 day old repo, extremely difficult in e.g. the VSCode repo!
For those of us who do utilize the pre-existing tools and the coding agents effectively, yeah automated code reviews eventually become redundant. But they're still around because there are a lot of devs who don't even glance at what the agents are writing for them. Maybe partly because they don't care to streamline their workflow, or maybe because they've never been particularly good at writing code, and don't actually understand what the agent is giving them.
Lately I've seen some pretty glaringly obvious issues caught during the preliminary automated code review, and the issues seem to be coming from individuals who don't actually understand what the code is doing.
For the rest of us who are actually using the whole stack effectively, the automated code review is essentially a CI gate to protect the repo from the devs who don't know what they're doing.
> But they're still around because there are a lot of devs who don't even glance at what the agents are writing for them
But how does automated AI code review help, here? Doesn’t it just reinforce that they don’t need to look at it (or change their habits), because the AI review will catch the issues?
"If AI inference remains as desirable as Kimball expects, the evolution is likely to follow the same trajectory as the CPU. The CPU didn’t improve along a single axis but instead across simultaneously. Once transistor scaling slowed, chip and system architecture innovations of all kinds proliferated. The list of individual innovations that led to today’s ubiquitous, powerful personal compute could fill dozens of books. A few decades from now, the history of AI inference innovation will show similar depth."
Of the areas mentioned in the article, which are the most likely to have the most prominent innovative impact, and what will they entail?
A large fraction of the innovation in CPUs is driven by working around the memory wall. I anticipate AI inference will follow the same trend, and innovations that work around the autoregressive nature will be enormously impactful.
Speculative decoding is an example. An accurate draft model can reduce the number of times you stream through memory by a factor of 4x.
How do you work around the memory wall when you're going to have to stream all weights, no matter what? Latency-hiding tricks don't matter when you're bandwidth constrained.
One of the biggest limitations right now is memory capacity (storing large models/contexts in memory) and bandwidth (transferring the relevant data/weights to the silicon that is performing the operations on that data). This would cover things like:
1. having more memory on the card/chip and/or faster access to that memory;
2. integrated memory and compute units optimized for matrix and vector multiply add operations;
3. optimized load circuitry to e.g. read memory in the stride and span (next row, next column) access patterns common to matrices or ensure that no/few parts of the chip are stalled waiting on data or operations to complete.
Another aspect is quantizations. These are similar to SIMD vector operations in that you are performing an operation on a block of n-bit data values at the same time, so can have optimized circuitry.
For 2 or 3 valued quantizations you can reduce various addition and multiplication operations to logic operations, avoiding circuitry for things like the half-adder, full-adder, and carry-lookahead.
Then there's adding specific circuitry for common operations such as ReLU like is done in hardware acceleration of image, video, etc. processing. There's a trade off here as optimized hardware would perform better at the specific operations but if those are too specific then they can't be used by different/newer model architectures. (Though it does make sense to try and optimize common operations/logic where possible.)
It would be interesting to see if these designs can/will benefit training as well, as that would bring down the time/cost/energy of training large models as well as making it easier for local fine-tuning.
Some kind of compute-in-memory architecture is a good candidate, I think. There are many alternatives here, researched for many years prior to the LLM craze. However economies of scale dominate in chip industries, and this tends to favor more conventional or incremental approaches (to piggyback on existing scale). Alternatively someone needs to have a way of bootstrapping the insane scales needed to be competitive with a better-but-different approach.
So it could be that boring and straightforward stuff like two-chip prefill+decode takes most.
Kayak fished the St. Croix river last year, on the border of Minnesota and Wisconsin, for smallmouth bass. Crystal clear water. Floated over several huge sturgeon, 4-6 feet long. The way they look, it feels like coming across a dinosaur. Thankfully they're bottom feeders.
Acipenser transmontanus are harmless sucker mouth fish, and lived in the local rivers long before our towns were even an idea.
They are usually strictly catch and release, but in a kayak could probably pull you a great distance. They are deceptively strong for their size, and a big part of local conservation efforts.
400 years is plausible, as they do live a long time when left alone. =3
My fishing story - as a young teen, I "caught" a sturgeon on the Ottawa River (just outside of Pembroke) in a 12' aluminum boat. This was in an area where we'd typically expect to catch bass and northern pike - our fishing net was maybe the size of a large diner plate, and reeling the fish in might take a minute or two.
My father was in the boat with me. After hooking the fish, it took about 20 minutes before the fish was close enough that we could see it from the boat, and identified it as a sturgeon - it was the only time I'd ever caught one. This one was so much bigger than anything I'd caught before. I was using one of those jointed Rapala lures, and it had hooked the dorsal fin. I can confirm the sturgeon could definitely pull the two of us, and the boat, upstream - but not a great distance - just enough to move the boat around.
After about 25 minutes, my line snapped (it may have been 12 lbs test). We didn't really have a way of getting it in the boat in any case, and we would have released it anyway. This was probably the late 80s/early 90s - so nothing captured on a phone camera - it just lives on in my Dad's & my memories...
The local tagged 80 year olds were caught so many times over the years they are surprisingly mellow about the inconvenience once landed in the shallows. Still, takes guts to attempt that in a dingy, as "You're Gonna Need a Bigger Boat" (Jaws, 1975). lol =3
> lived in the local rivers long before our towns were even an idea
To be fair, the towns you're talking about are barely 200-300 years or so I presume? Most other towns in the world are probably older than those towns, and maybe even the fish if it's just 400 years ago :)
To be fair the towns a North American might be talking about could easily date to 400 to 600 years ago at least - with signs of human occupation in the Great Lakes area going back 10-12,000 years before present, a good deal on the present lake floors.
Where I live on the West Coast any towns older than a couple hundred years are long gone, the people were killed or evicted from their land long ago. The existing towns are all new.
Towns are where people live, buildings come and go - Manitoulin Island, within the Great Lakes, still has the Wiikwemkoong First Nation unceded and occupied land, near to which French Jesuits set up a mission in 1648.
reply