Yes, but not for you and me. Graphics designers have been using stylus-displays for years and years, because it's great to draw on the thing you are making instead of drawing on a different surface like a Wacom.

But I'm like you, I don't have a use case for a touchscreen and if you touch my notebook screen I'll be angry because I prefer it without fingerprints, thanks. So my first question is: Do they offer this thing with OLED but without touch? I guess not. Pity.

I've been slowly moving towards my dream setup: Solar panels, battery, EV car, island mode capability. This is one thing that'd be a factor in my buying decision. Using your car as a battery or secondary battery is a big plus, and if they built the necessary equipment to run independent of the power grid, it'd come in a neat package.

While power failures are rare where I live, I expect them to become more common with the move to renewable energies. I support that, but it's more fragile than constantly running power stations. So being able to run your home at least for a few hours on your own energy is something that I consider a good idea.

You missed the point.

A friend of mine made a tea-timer app for the iPhone. Where you enter what tea you are making and it sets the correct number of minutes. Today, people would ask ChatGPT before they go on the App Store to search for something like that. That's the point. Not what YOU would do, but what the general public does. And for Jane Doe, ChatGPT has replaced a lot of these specialty apps.

Skills are great until they aren't. The problem is exactly what you say: You can literally create a skill by telling the LLM to create a skill. Which is... why the f do I need to make a skill if the AI already knows how to do it?

Properly created skills, that include reference material, specific instructions, and expert knowledge the LLM doesn't have or that's buried somewhere under 10 layers of reddit posts is genuinely useful. But most skills aren't. I'm constantly underwhelmed by hyped-up skills that, when I look at them, turn out to be bland, basic instructions.

Only in the most utterly pedantic sense of the word "different" wherein you mean that by definition, infant mortality occurs early and wear occurs later. But they can both stem from the same root cause, which is a component not built with adequate tolerances. In other words, they can be the same fundamental issue, just expressing themselves at different times.

Most products don't have an MTBF. And things that do have MTBF are based on accelerated wear testing on a small number of units, and can have almost zero basis in reality. There was one model of major brand hard drive about twenty years back where a couple of RAIDs where I used to work got lost because the drives all died after such a predictable number of powered-on hours that by the time you could re-stripe the RAID, the next drive would die. They ended up making sure the drives had a high variance in powered-on hours before using them in RAIDs after that.

It's an example that proves or demonstrates a point. And the point it was proving was that the same root cause can be responsible for both catastrophic early product failures and premature deterioration-related failures.

I like the idea of a folding phone. I really like a flip phone for something smaller to carry around.

But I'd never go back to a phone with moving parts. Just way too much stuff to break. No phone I've had with moving parts ever lasted longer than 2 years. I'd much rather just carry around a regular slab phone. They last so much longer.

Wear-out failures aren't always different from infant mortality failures, though. If the defect is caused by a design flaw in a component resulting in a structural weak point, that same weak point could fail after one use or a thousand, and it could just be a ticking time bomb. Someone could get very unlucky and find one that is slightly weaker, and it could break much sooner.

Case in point, I recall a machine where some people would have to have their laptops replaced every couple of months for motherboard failures, while others lasted for years, and it turned out to be dependent on how people closed their laptops at the end of the day and whether they pressed on the bottom of the case in a particular spot that wiggled the GPU. But if you handed one that had been working for five years to someone who used their left hand under the laptop while closing it, it would be dead in two or three months. If you replaced it with a brand new one, the brand new one would be dead in two or three months. And so on.

But again that's backwards. I let my AI coding assistant write tests exactly so that I have a reproducible, deterministic ground truth that I can inspect for logic errors. If you let the AI do the testing directly, it's a toss-up if today it feels like it or it decides that your desired result is "everything green" so it'll just give you that answer without actually testing anything.

LLMs obviously aren't human. But that's not the point. The point is that you don't need to know a programming language to program a computer.

For example: Especially in the early days of smartphones, there were mountains of small tools that did something that's essentially a simple script. Egg timers, remind-me-tomorrow apps, tons of stuff that's basically a wrapper around a web search, and so on. Almost all of those are today something ChatGPT can do, and are easy enough to describe.

I've actually outsourced the first iteration of that to AI. :-)

At the end of coding sessions, I generall ask it to spin up an adversial agent whose task it is to find flaws, inconsistencies, mistakes, bugs, etc.

I'd still strongly recommend to anyone shipping AI-generated code to have a thorough human code review, but for a first pass at surface level, the AI can check itself if it has some kind of separation between the generator and the reviewer.

Personally, after some experimenting, I've concluded that:

• AI is good at implementing known algorithms.
• AI is good in creating code that flows straightforward from a design document.
• AI is good at code reviews and finding bugs.
• AI (unlike me) doesn't mind writing a few hundred tests.
• But, it tends to over-engineering simple tasks to the point of "why does Hello World need enterprise-software levels of abstraction?"
• It struggles with code that doesn't have a known solution.
• It's difficult to get it into a different lane once it started going down the wrong way.

What I use it for these days is rapid prototyping. Using AI I can make a functioning prototype of an idea I have in a few days instead of a few weeks. I can quickly test out an idea for a feature or change in my existing codebase.

What I also have been using it for a while is as a code-reviewer and for someone like me who is mostly working solo, that's an insanely valuable thing. Not just the bugs themselves, but also the ability to discuss code with someone. Basically, AI is a rubber ducky that replies.

Mickeysoft lost the plot again.

The game-changing element of LLMs and agents is that they have a non-computer-language interface - you can talk to them in plain English (or Chinese or whatever). This makes complex computer interactions available to a much wider audience than any previous computing invention. Adapting humans to the AI is getting that backwards. It's a sign you don't understand the first thing about why AI is so widely successful.

I predict this will be an abject failure and a year from now will quietly be pushed to the very back of the bottom-most drawer, never to be spoken off again (though it is getting crowded in there for M$).

Meanwhile, in the real world, everyone I've talked to about these things already has a skills file to teach the AI about their personal coding style. This is what actual humans came up with, independently several times, and it works: Adapt the AI to you. Plus we've been writing coding style guides for humans for a long time now, we've got plenty of experience doing that at least somewhat right.

This is why I say that users shouldn't be the target of the training. HR, marketing, and the C-suite should all be forced to take classes in how to NOT send scammy mail. DON'T send internal mail that links to an external site. DON'T send internal mail with an external From: line. DON'T send mail asking your employees to reply with passwords, encryption keys, or BitLocker recovery codes. DON'T use Mail Chimp or a similar email processing house for internal mail. I've seen all of these things done, and every single one of them trains your employees that it's okay to click on any arbitrary link because they expect legit internal mail to contain any arbitrary link.

Yeah, and their whole argument is irrational. $1500/$30 = 50 months. A four-year ROI isnâ(TM)t irrational. Whatâ(TM)s irrational is companies expecting to make back their costs in a year, and expecting that because their service sucks so much that people wonâ(TM)t stay past the promotional period.

In my experience, most sufficiently advanced use of PHP involves rendering the HTML. You can do it either way.

And most sufficiently complex PHP uses PHP as a full-fledged language, complete with classes, etc., and to the extent templates are used, the code in them consists of tiny partial-line-long fragments of code that call some method in some other file that is basically just code.

In other words, very fragmented code isn't caused by PHP; it's caused by the way that the developer chose to use PHP.