Oh, no question that it's a hard problem. The difference is that self-driving can be broken down easily into a bunch of smaller hard problems, and each problem has, to some extent, a right answer, or at least relatively straightforward ways to objectively verify that an answer is not wrong. For example, you can fairly objectively define what constitutes a reasonable driving path, and provide guard rails in running your tests against newly trained models that fail if it goes outside of those parameters. So this is more in the NP-complete level of complexity, where computing it is hard, but verifying the solution is of polynomial complexity.

What constitutes a reasonable architecture for piece of software is either entirely subjective or an intractably large set of objective constraints or some combination thereof, because maintainability considerations play a role, along with data backwards/forwards compatibility, etc. I'm not even sure where you would begin trying to define adequate guard rails. This is more like the broader NP-hard level of complexity, where computing it is hard, and verifying it may well be even harder.

No disagreement on any of those points. The tolerances for self-driving car tech are indeed higher than the tolerances for tools that write software. But part of the reason for that is that there's a human in the loop in the latter situation. You aren't trying to write software that can design a word processor from scratch. You're writing software that can design a single function or maybe a small class that performs a specific behavior from scratch, and all of the hard work happened before you even asked — specifically, coming up with the specifications.

I know that's true for self-driving as well, but the difference is that the specifications for working self-driving behavior are largely consistent across platforms, with the exception of some specific rules of the road being different in different countries, whereas the specifications for a word processor are entirely unrelated to the specifications for an image editor or a web server.

So at that general level, being able to drive a car is at best like AI being able to write a word processor, and AI being able to write any arbitrary piece of software is by definition a much broader problem.

Probably not. The robotic vacs can be used entirely offline; you just lose the ability to control it remotely if you do. And if you believe their privacy policy, no data is stored remotely except for aggregated data.

I mean, that's the very definition of AI.

That would be Cruise, I suspect. The general perception of Waymo in SF seems to be pretty positive.

I wouldn't call it "highly confined". The biggest constraint was lack of support for driving on the freeway. They just started testing that in early 2024, and got regulatory approval in California in mid-2024. Without freeway driving, self-driving cars wouldn't be feasible in a lot of cities. Now that they've started doing freeway driving, I suspect you'll find that the number of situations and environments that they can't handle is remarkably small, bounded largely by the need to do high-definition mapping drives first.

I agree that it is imperfect, particularly when construction is involved, but the difference between the modern Waymo cars and the hesitant Waymo cars from a decade ago is night and day, speaking as someone who periodically ends up driving near one.

I disagree on the first part, but I agree with the second. I have little faith in any mass-manufactured humanoid robots being usable right now. But if they bring the cost of the hardware down enough through mass manufacturing, then as long as they run some sufficiently open operating system, other folks will find interesting ways to use them, and will figure out how to make the software work.

For example, electronics PCB manufacturing is already highly automated, with human workers loading tape reels of components into pick-and-place machines, and the machines doing all the rest. It would be hard to replace all of that hardware with new hardware designed for any sort of automated loading, but it seems obvious that a humanoid robot with the right programming could fully automate the loading of components. That's well within the realm of what robotics can do today.

Similarly, Amazon warehouses have non-humanoid robots that can already pick a lot of things off of warehouse shelves. A humanoid robot could probably do a better job, and they actually have the software engineering resources to make that happen. Whether any of that software would ever become available outside of Amazon is, of course, a different question.

Making a choice at its simplest is an if statement. It's boolean logic. Making lots of rapid choices that take into account the data coming in can be measured objectively. Creative efforts can only be measured subjectively. That by itself makes the two fundamentally different in terms of designing training systems.

Let's be realistic here. On 99% of drives, nothing interesting happens. You just have to pick the correct lane, stop for stop signs and traffic lights, and obey the speed limit, and you get there safely. For 1% of drives, somebody cuts in front of you or tries to sideswipe you or steps out in front of you. And for the 95% case, you just have to recognize that this is about to happen by computing the speed and direction of each vehicle, pedestrian, animal, or other large object, and hit the brakes soon enough. By the the time you get into situations where you have to steer to avoid something, you're at more like .0001% of drives.

This, of course, ignores the path planning headaches of some drives involving driving through safety cones for temporary lane shifts, or on rare occasions, having to deal with a human directing traffic, but again, these are relatively rare edge cases.

Which means it's not a similar sequence at all from a complexity perspective.

In driving, once you have passed a particular spot in the road, what happened back there no longer matters. You can forget about it. And anything that isn't about to happen within the next double-digit seconds also doesn't matter. You don't need to think about it yet. There's a very narrow window of temporal data that matters.

In programming, every single one of those decisions has to take into account at some level every future decision that will lead to successfully building the app, not only immediately, but also making it maintainable for features that you might want to add later. You can't look at one part of the project in isolation, do your job, and walk away unless you are a very junior programmer working on a very well-defined task. And if you are a very junior programmer, for you to even be able to get that well-defined task in the first place, someone else had to think about all of those things; it just wasn't you.

So no, these are not similar. Not at all. The decisions made by a self-driving car are expressible as a simple state machine, with simple outputs (steer X% left or right, brake x%). All of the complexity is in the data gathering (get the location and motion vector for all interesting objects) and path planning. The decisions made by a programmer are not. The inputs are vague English descriptions of what you want to build. The outputs are large, complex software systems.

I'll grant you that snow is a problem. It's also a problem for human drivers, though. Random objects? They're about as likely in the Bay Area as in any other city.

Actually, quite the opposite. Driving usefully in a dense city with pedestrians and cyclists is worst-case for self-driving tech. Driving out in the middle of nowhere means you're orders of magnitude less likely to encounter other cars, pedestrians, and cyclists, so the decisions tend to be way less critical. Obviously, the lack of updated maps can be a problem, but that's more of a process issue, not a technology issue. The only other real difference is the potential for higher road speeds, but a car's ability to drive at higher speeds is mostly bounded by CPU/GPU performance and camera resolution for seeing things at longer distances, i.e. it is the sort of complexity difference that will go away on its own with a few years of hardware improvements.

Yes, it does. Thanks for asking. i've read Tesla's privacy policy, and it seems entirely reasonable. Same with Roborock. If that changes, I'll let you know.

If you think companies are going to keep using Windows for their embedded devices when the company has to create an online account before they ship the box to customers, you have another thing coming. Letting the manufacturer of a product have permanent control over that hardware and permanent ability to take control over someone else's account on a device that they own would be a showstopper for literally every company that preinstalls Windows for embedded use.

The thing is, they could shut down and guarantee that with 100% certainty. Making it harder for someone else to get certs for your domain is nice until it prevents you from getting certs for your own domain. Also, it does nothing for the gaping hole that lookalike domains represent.

As far as I am concerned, TLS certificates stopped being beneficial when they stopped costing thousands of dollars. Expanding TLS to every random person who wants to run a web server destroyed their value in recognizing a site's legitimacy. For everybody else, we should have used a separate system, like public keys in DNS records with key pinning a la SSH. Instead, they basically broke TLS completely, so the security icon in Safari for Amazon.com is indistinguishable from the security icon in Safari for my personal website with a free certificate from LetsEncrypt.

From here on, there's nothing that they can realistically do to make TLS trustworthy, because it just isn't. They could make it impossible for other people to get certs for your sites, and that still won't make it more trustworthy. For 99.9999% of use cases, we'd be better off if they stopped trying, let anybody get a cert who wants one, and used key pinning to guarantee that fake certs are useless except at sites you haven't visited. If you have pinning, the only remaining benefit for actually validating the ownership of the domain is for extended validation certs, and again, if you can't tell which ones are which, then the industry has decided that they don't matter, so why bother with that?

In other words, the whole industry is basically a useless tax on the web at this point, and should go away.

No, not really. Being a good programmer is a creative process involving design aspects, low-level coding aspects, naming things (one of the two^H^H^Hthree hard problems in computer science), and generally figuring out how to express a vague general concept as a series of strict rules.

Driving safely is just combining GPS routing (which is a long-solved problem) with obeying a bunch of fairly well-defined road rules and recognizing hazards and stopping or steering when you see one &mdash identification, path planning, etc

There are several orders of magnitude difference in the difficulty of those two tasks. That's why we have generative AI art with six fingers and two thumbs, while self-driving cars are operating commercially in multiple cities.

AI is already replacing drivers. Right now, you can take a ride in a self-driving car from Waymo in Phoenix, much of the San Francisco Bay Area, Los Angeles, and Austin, with 10 more cities rolling out this year. Their at-fault accident rate blows human drivers out of the water. I mean sure, you still have the occasional bizarre story about someone circling a parking lot for twenty minutes or the cars honking at each other all night in a parking lot, but arguing that self-driving car tech isn't mostly a solved problem is disingenuous at best. Tesla mostly has it working on highways. Waymo mostly has it working in cities. Put the two together, and you could at least ostensibly have end-to-end autonomous driving from coast to cost.

Doing autonomous driving well enough and cheaply enough to have it in a vehicle that individuals own is, of course, still not fully solved, and doing it generally in every environment without having to block off certain areas because of construction, etc. is also still not entirely solved, but that's like arguing that robots can't replace vacuum cleaners because they can't get into corners. For the 95% case, it is solved, and that's actually pretty amazing, IMO.

Posting this as I eagerly await the HW4 upgrade for my Tesla and the arrival of my new robotic vacuum cleaner in May.

I think there's a big differences between self-driving cars and using AI to replace programmers. There's no feasible way to have enough cab drivers and Uber drivers for everyone to stop driving themselves, nor will public transit ever get good enough to be a good alternative to a car outside of large cities. So self-driving car tech is doing way more than just replacing the small number of people who drive for a living. It is also giving mobility to the elderly, giving several hours per week of commute time back to the sorts of workers who can work remotely during the commute, driving down the cost of package delivery and reducing delivery times, and massively transforming probably a lot of other markets. And that is likely to result in more jobs, rather than fewer overall, albeit fewer in a few narrow areas.

The same can't be said for using AI to replace workers in most other areas.

Or find someone with the same model and borrow a laptop.

If it turns out to be a bug that's reproducible on the same model of laptop with that monitor, consider getting a free Apple developer account and filing a bug with Feedback Assistant, which will capture logs and submit them to Apple.

You misspelled Snow Leopard, or maybe Mountain Lion. :-D

But seriously, I mostly blame the decision to merge Mac and iOS development. It took three years for the iOS side of the house to drag the Mac side down enough for you to start noticing, but having them under the same team resulted in constant attempts to merge these very different platforms, always to disastrous effect. The downhill slide for macOS began very clearly when Forstall left Apple and iOS got merged under Craig. Nothing against Craig here — I think he does a great job, or at least he did when I worked under him — but the teams should never have been combined.

Mavericks had some nice changes at a low level; the UI changes were questionable, but not objectionable.

Yosemite went too far, IMO, though users seemed to like it, I guess?

By the time you got to El Capitan, we were calling it "El Crapitan".

I haven't really seen anything of value added since then other than Apple Silicon Support. And that's okay. It's an OS. It doesn't have to constantly change and add new features. At some point, all you can really do is make it worse, and I think they passed that point a while back for the most part. :-)

This is not normal. You almost certainly have either defective VRAM or a defective GPU. For the M*-series, those are the same thing.

Chances are, an address line is marginal, so sometimes data is getting written to the wrong part of VRAM.

I mean, there's a very, very tiny chance that it could be a software bug where VRAM is getting simultaneously allocated to multiple processes at the same time, and given that you're right on the threshold of running out, that's slightly more likely than it otherwise would be, but my money is on hardware.

What I would do is bring your computer and monitor to an Apple store and show them what's happening and then try it with the same monitor on a different Mac and see if the problem reproduces. When it doesn't, tell them you need a new logic board.

If you're being sarcastic, know that this very much has happened.

• It used to be the case that you could make high salaries doing manufacturing in the U.S.; now, most manufacturing is highly automated and has fewer workers (and is overseas).
• Doctors have always been some of the best-paying jobs out there, but insurance companies (both health and malpractice) have been squeezing them from both sides, and technology has been pushing up from the bottom to make it easier for nurse practitioners with less training to do more of the jobs that doctors can do with supervision that is becoming less and less, and the result is that most doctors now are imported from other countries, in part because not enough people are going to medical school and in part because the people who do go to medical school are choosing to do research instead of actually practicing medicine. Being a doctor still pays well, but the relative pay has dropped, from 3.47x an average college professor salary in 1980 to just 2.81x today.
• Speaking of medicine, the entire field of medical transcription has basically been replaced by tech.
• We're about to see truck driving go the same way as self-driving tech replaces that previously moderately high-paying career.
• We're seeing hints that generative AI may start to impact tech as well.

What makes this different right now is that the rate of job destruction seems to be accelerating, probably at a faster rate than the market can adapt to.

But now, those folks can use generative AI to become crappy low-end programmers writing tests for a software company, or to become staff writers for Associated Press, or whatever. They move up to higher-level jobs because they can, and the lowest-end jobs go away and are *maybe* replaced by higher-end jobs, though that's the giant open question.

Except that the AI also gets better at helping people with less training to do that design and architecture work, which means more people become capable of doing that work, which means the value to the firm declines, and the salary they pay declines with it.

As the overall productivity of the people increase, there are more people who can do the work at each level, so perversely, it encourages companies to pay them less.

Both. There are labor shortages because there aren't enough people willing to work for what companies are willing to pay to get that work done. And AI is going to effectively destroy many of the remaining jobs that currently pay a decent salary.

For the most part, AI isn't going to reduce the number of jobs except for jobs that require limited training or intellect. In fact, it might even increase the total number of jobs. Rather, what it will do is shift the jobs right, making jobs that previously required years of training possible to do tolerably with days of training, thus decreasing the number of middle-income jobs and increasing the number of minimum wage jobs, or worse, the number of jobs in third-world countries where they can pay people a dollar a day or whatever.

In other words, it won't decrease the number of jobs, but rather, it will decrease the number of jobs that pay a living wage.

The rich get richer, the poor get poorer, the middle class erodes, rinse and repeat.

If by robots, you mean outsourcing all the manufacturing to lower-wage countries followed by eventually replacing *their* labor with robots, then yes. If you mean in a single step, not so much. :-D

And if there's no labor involved in making something, it's hard to justify charging for it, especially once the means of producing the robots becomes fully automated, because it's a mostly self-repairing cycle at that point. It's a good thing, too, because there won't be any money to pay for the stuff once the robots take all of the jobs. This will, of course, take decades, and it's unclear whether other jobs will replace those jobs, or what those new jobs would look like.

You misspelled "billion". Modern robotics can replace pretty much all physical labor, given sufficiently advanced AI control. You probably need humans periodically inspecting the work to make sure it is being done correctly, but it's easy to imagine robot builders being able to build houses without any human involvement except a weekly inspection, and doing it in a fraction of the time. It's easy to imagine end-to-end robot manufacturing from the mines all the way to the customer. It's easy to imagine robot trucking and package delivery and pizza delivery. It's easy to imagine ordering food cooked by a robot using a touchscreen and paying for it by tapping your phone.

The only thing that can't be automated is programming the robots, and even that is just a matter of time before the bots can learn from a human performing the actions and then replicate the process in code form that can then be mucked with by a human adding extra conditions and safety checks and similar whenever things go wrong.

The companies investing in AI development usually aren't the companies that can cut people because of AI, for the most part, so most of that is likely a smokescreen to pump up the stock price by making it look like they're making progress without spending money, hoping that their investments in AI start paying adequate dividends before sufficient damage to their existing products and reputation comes back to bite them in the a**.

The companies that can cut people with AI are mostly companies like Amazon and McDonald's. Of course, Amazon is actually investing in making AI, too, being at least in part a tech company, so they're one of those few exceptions where a single company can do both simultaneously.

Mostly, it's because AI makes it possible to easily but badly automate things that couldn't be easily automated before. So you have the opportunity to, for example, create a customer service experience that's a total disaster, but costs almost nothing, rather than a customer service experience that's merely bad, but expensive.

In other words, look for the companies doing this right now, and don't buy their products, because it's usually safe to say that they don't care about their customers at all. In ten years, the companies doing this will be the companies that waited until the tech was actually good, but the ones replacing people with AI right now, not so much. :-)

Certainly true. On the flip side, there's also a decent chance that most of those jobs weren't real, and existed primarily to provide "proof" that they couldn't find someone in the U.S. so that they could get H-1Bs. :-)

Except that those articles were misleading. Software engineer jobs as a whole are up. Only "programmer" jobs are down. Basically, the lowest of the low-end jobs decreased significantly while the total number went up.