Just a few minutes ago, while copying 63 GB worth of pics and videos from my phone to my laptop, KDE forwarded me the error "File <hard to retain name.jpg> could not be opened. Retry, Ignore, Ignore all, Cancel".
This was around file 7000 out of 15000. The file transfer stopped until I made a choice.
As a user, what am I supposed to do with such a popup?
It seems like a very good example of "Eror Handling Without Purpose" as the article describes, but at user level.
Except that here, the audience is "a plain user who just dragged a folder to make a copy" and none of the four options (or even the act of stopping the file transfer until an answer is chosen) is actually meaningful for the user.
The "Putting It Together" for this scenario should look like: a non-modal section populates with "file <hard to retain name.jpg> failed due to reason; at the end of the file transfer you'll get a list with all the files that failed, and you'll have an option to retry them, navigate to their source position to double-check, and/or ignore".
> As a user, what am I supposed to do with such a popup?
Change the floppy disk. In the MSDOS days those messages were useful, as read errors might be caused by having the wrong floppy in the drive. The OS had no way to know when the floppy was changed and "Retry" allowed you to swap the disks back and try again. In modern days it is less useful, the behavior just got carried over.
Windows addresses this issue somewhat by scanning the directory tree before the actual copying starts, this can catch some errors before they happen and gives you better progress reporting on top.
But a single dialog that keeps track of the whole copy/move operations, not a modal dialog attached to individual read/write calls would be the way to go here. This is a case of the GUI sticking to close to what the OS is doing instead of what the user intended to do.
> Windows addresses this issue somewhat by scanning the directory tree before the actual copying starts
Which really sucks because no you need to wait for minutes before it actually starts moving or deleting. I generally just abort, start the midnight commander or just invoke mv/del directly.
> But a single dialog that keeps track of the whole copy/move operations
Which is what is the case here? The question and buttons appear in that dialog.
The error/retry dialog is for the failure of moving an individual file, not for a failure of the move operation as a whole. Those individual error dialogs provide no means to deal with cascading errors. All you can do is "Skip All", but that means you get no further information on errors anymore.
The error reporting should be part of the Moving dialog itself and provide a list of everything that failed in the move, along with potential ways to resolve it. More detailed reporting than "Could not read" would also be welcome (io, permission, ...).
This design still doesn't work: what if the user walks away and the computer is powered off in the meantime?
I.e. you need to write the report of this to a file itself. In fact you should allocate a decently large file upfront to make sure you can write the report and the error message (out of disk space for example).
A file transfer should remain active even if both devices (source, destination) are physically disconnected, or in network partitions, or when devices are full, need media change, etc.
The only valid states for a file transfer are: ongoing, fully completed with 100% success, or explicitly cancelled by the user with a full usable report of what got copied, fully or partially, and what did not get copied.
The file transfer dialogs and tooling of today's mainstream computing are stuck in the nineties.
> kidnapped by the US Army.... You just can't defend against everything
Of course not.
The litmus test IMO should be "what would a normal intelligent human do in this situation?"
A human would copy every file it could, maintaining a list of issues. When you were available to address concerns, it'd present the options to you. The human would give up if the US Army showed up, but a human would restart a TCP connection automatically without asking for permission again (or more analogously, redial a phone call). A human would save their work automatically, and when you showed back up, would find that work for you.
(In 2026, things like "retry" should be automatic outside some very specific limitations too, because of course a human would try again if they failed).
> what would a normal intelligent human do in this situation?
Problem is that this requires testing what actual "normal intelligent human" would do, because very often programmer has other ideas and UI/UX people have other ideas.
> A human would copy every file it could, maintaining a list of issues.
How do you know? From your idea what should be done instead of current version? I would not do it like you said.
Also, there are many reasons for transfer not succeeding and depending on a reason why transfer didn't succeed, you should make different decisions. sometimes reasons are not predictable by a program (a new file transfer method over pidgeons was transparently added to the system and "carrier attacked by predator" was not included in "how to handle this reason").
No, but imagine doing all the work to collect up a list of files that failed only to say, pop a modal at the end of the process that coincides with the user hitting Enter because they were multitasking and it auto-accepts the dialog. Information gone, context lost, in fact your entire design has failed to change the experience at all! All because of one UI overlap that's actually very common.
We have shared workstations for example where this would be a typical use case for non-tecchnical users across multiple user logins: ensuring you can check that the big data transfer was complete a few hours later would be very useful, but if you only do a fraction of the work for completeness then again, it's of no benefit.
Yes. The entire reason DEs expect people to dismiss those dialogs is because they are modal. And there's no reason at all for them to be modal.
KDE even got an entire notifications application, and discovered that it's bad to make them modal. But didn't move away from the idea of dismissing them on any interaction, it still acts like it's a modal.
> Step 1: Connect (CVE-20700/20701) The attacker is in physical proximity and silently connects to a pair of headphones via BLE or Classic Bluetooth.
> Step 2: Exfiltrate (CVE-20702) Using the unauthenticated connection, the attacker uses the RACE protocol to (partially) dump the flash memory of the headphones.
> Step 3: Extract Inside that memory dump resides a connection table. This table includes the names and addresses of paired devices. More importantly, it also contains the Bluetooth Link Key. This is the cryptographic secret that a phone and headphones use to recognize and trust each other.
> Note: Once the attacker has this key, they no longer need access to the headphones.
> Step 4: Impersonate The attacker’s device now connects to the targets phone, pretending to be the trusted headphones. This involves spoofing the headphones Bluetooth address and using the extracted link-key.
> Once connected to the phone the attacker can proceed to interact with it from the privileged position of a trusted peripheral.
It's objectively not a popular feature or something the vast majority of consumers are looking for.
Most people prefer Bluetooth because you don't need to deal with annoying wires getting tangled, ripping your earbuds out, etc.
Again, it's not that the market asked for the jacks to go away, they just don't care. And when there's something that consumers don't care about, companies tend to remove it. The jack takes up volume. Not huge, but on phones every cubic millimeter counts. And it's one more thing that can break.
And if you really want a jack, there's a $9 adapter you can just keep attached to your headphones. So everyone wins.
The survey asks whether people care about the headphone jack, though – it asks whether it's in the top three features they care about.
I care plenty about the headphone jack but still reluctantly bought a phone without one (which I regret) because I have more than three requirements to balance. I expect that the users who did include the headphone jack in their top three features still care that e.g. the screen, battery and radio are all in working order as well, despite not being in their top three.
> Most people prefer Bluetooth because you don't need to deal with annoying wires getting tangled, ripping your earbuds out, etc.
Thanks for this summary. I feel sad to be in a minority who prefer wired headphones. For me it's because all their failures you listed are issues I can understand and mitigate. But when bluetooth goes wrong, what do I do? Usually:
1. turn off both devices and then turn them back on again
2. try to reconnect
3. if step 2 failed, give up and try again another day
I don't learn anything. I feel infantilised and helpless.
Yeah, I think that's why a lot of people stick to same-brand or trusted brands -- AirPods "just work" with iPhones, in ways that other Bluetooth earbuds don't always.
I understand the figured sense that you describe. It reverses the logical suite of cause and effect. Instead of describing the true cause (Apple chooses to drop the jack) and the consequence (customers "don't care", which I believe is wrong), the conveyed message blames those without a choice: "customers don't care, therefore we should drop the jack".
The survey that you link is built on the premise that "you can pick only three things at most" as a manipulative trick. And since the headphone jack doesn't make it to the top 3, you use it as claim that consumers do not care about the headphone jack. This is not reasoning or stating objective facts, this is just a cop-out.
My claim is that the vast majority of consumers still need at some point in their use of their phone a way to plug 3.5 jacks into their phones somehow, and just put up with the enshittified new way: either buy some bluetooth adapter dongle, or a USB-C low quality DAC, or just give up and find a different solution.
"few customers care" is not the democratic ideal you make it sound to be.
It's the same as glued batteries, unrepairable phones. Few customers making it an absolute criteria for their phone choice still doesn't make mean the majority sees it as a positive thing nor they agree. At the time on the android side, only Pixel and Samsung's lines were serious about the camera or international NFC support, moving to other phones just for the jack came with huge compromises that had nothing to do with the jack itself.
It’s a competitive market. If removable batteries mattered to a lot of people, some company would take advantage of that to make a lot of money.
Feature combinations aren’t immutable facts of nature. Manufacturers make a conscious choice about what to include. If a good camera and international NFC combined with a headphone jack would attract a lot of buyers, don’t you think Samsung or Google would make a phone like that to better compete?
It’s nothing to do with “democratic ideal.” It’s about understanding that companies want to make money and if a feature is desirable, they will leverage that in their quest to make money. Some may fail to understand what their customers want, but all of them? It’s not plausible.
The "???" is "hey, Apple are doing it! since we already copy so many ideas from them, let's shave a few cents on the amp and jack receptacle, and if anyone complains, just claim that it's the trendy thing to do now".
And why didn't any of the multitude of phone makers say "turns out that people actually want a headphone jack, let's spend a few extra cents and steal all of our competitors' customers"?
Almost like there were at least three other features more important.
The most important letters in English are E, T and A. I'm sure you won't notice if we remove H from all keyboards, right? After all, the survey says it's not in the top three. And given a choice between a keyboard without E and one without H, nobody buys the one without H, proving they really don't need the H.
Why wouldn’t some keyboard manufacturer realize that a lot of people actually do need all of the letters, sell a keyboard with all of them, and make bank?
This theory that people want headphone jacks and phone makers won’t provide them makes no sense. It requires phone makers to be so cost conscious that they’ll remove a desirable feature to save a few cents, yet simultaneously so clueless that they won’t take advantage of consumer preferences to beat their competition. This sort of thing happens with individual companies, but not with every single company in a competitive market with many competitors.
I don’t know why people can’t just accept that they have a minority preference. There’s nothing wrong with that. I’m sure it’s far from your only one (I have plenty of my own, just not this one). There’s nothing wrong with general complaints that the market doesn’t cater to your minority preference. But arguing that it’s actually the majority, when it plainly isn’t, it just weird.
Because a large number of “everyone” is buying keyboards from your competitors. If you make a keyboard with all the letters, you’ll get more of those sales.
No, I wouldn’t but a keyboard with a tm key because I don’t care about having such a key. Pretty much nobody would. That’s why such keyboards aren’t made. You’re making my argument for me here.
Counterpoint: if, instead of differentiating yourself, you copy Apple, nobody will fire you for that decision, even if it sucks.
Bonus: now that neither you nor Apple are including the jack, consumers resign themselves to a worse user experience and just buy your product (or theirs).
The source is the fact that very few phones have them.
There isn't some grand conspiracy to keep headphone jacks out of phones. Why would they do that? You think Samsung or Google wouldn't jump at the chance to sell more phones by putting in a headphone jack, if that would actually help them compete? No, the reason few phones have one is because few people care about it, at least enough to influence their purchasing decisions.
There are plenty of examples of market failures in the world where lack of competition or information prevents consumer preferences from being reflected in product offerings. But smartphone hardware is definitely not one of them.
Using kde on Wayland for a while now, on a Nvidia card (debian trixie, just upgraded to forky a week ago), and i can't relate to any of those issues. My only complaint is a silly kernel module warning that pollutes my syslog.
They belong in the same category: the end user has zero agency over how their privacy is impacted, and is at the whim of the wishes/agency of whoever is serving content to them.
Whether the one serving the content is exploiting data at the present moment has very little relevance. Because the end user has no means to assert whether it is happening or not.
Consider Poland. 80% of its electricity production (as of this moment, almost midnight) is coal + gas (and it imports from Germany). Its generation mix results in 855 grams of CO₂ per kWh.
Consider Germany. 50% is coal + gas, 22% is wind + biomass. At 490 g/kWh.
Italy: 60% gas at 386 g/kWh.
Then compare them to France: 75% of the electricity comes from nuclear, at 47 g/kWh.
All of this despite abundant wind+solar capacity installed in Germany, France, Italy, and Poland.
There is a strong need to remove CO₂-intensive generators and replace them by something that does not send CO₂ into the air.
There is also a strong need to build up capacity to store energy.
When I studied computer science, the artificial intelligence practical courses were things like building a line-follower robot or implementing a border detection algorithm based on difference of gaussians.
Anyone calls anything "AI" and I think it is fair to accept that other people trace the line somewhere else.
I think I'd define "classical" AI as any system where, rather that putting in an explicit algorithm, you give the computer a goal and have it "figure out" how to achieve that goal.
By that definition, SQL query planners, compiler optimizers, Google Maps routing algorithms, chess playing algorithms, and so on were all "AI". (In fact, I'm pretty sure SQLite's website refers to their query planner as an "AI" somewhere; by classical definitions this is correct.)
But does an SQL query planner "understand" databases? Does Stockfish "understand" chess? Does Google Maps "understand" roads? I doubt even most AI proponents would say "yes". The computer does the searching and evaluation, but the models and evaluation functions are developed by humans, and stripped down to their bare essentials.
RMS might say yes, here's from the linked page describing other things as having knowledge and understanding:
> There are systems which use machine learning to recognize specific important patterns in data. Their output can reflect real knowledge (even if not with perfect accuracy)—for instance, whether an image of tissue from an organism shows a certain medical condition, whether an insect is a bee-eating Asian hornet, whether a toddler may be at risk of becoming autistic, or how well a certain art work matches some artist's style and habits. Scientists validate the system by comparing its judgment against experimental tests. That justifies referring to these systems as “artificial intelligence.”
Thanks -- that's not at all clear in this post (nor is it clear from the link text that its target would include a more complete description of his position).
I've updated my comment in response to this. Basically: It seems his key test is "Is someone validating the output, trying to steer it towards ground truth?" And since the answer re ChatGPT and Claude is clearly "yes", then ChatGPT clearly does count as an AI with semantic understanding, by his definition.
> I think it is fair to accept that other people trace the line somewhere else.
It's a pointless naming exercise, no better than me arguing that I'm going to stop calling it quicksort because sometimes it's not quick.
It's widely called this, it's exactly in line with how the field would use it. You can have your own definitions, it just makes talking to other people harder because you're refusing to accept what certain words mean to others - perhaps a fun problem given the overall complaint about LLMs not understanding the meaning of words.
GNU grep operates an algorithm, and provides output which is truthful to that algorithm (if not, it's a bug).
An LLM operates a probabilistic process, and provides output which is statistically aligned with a model. Given an input sufficiently different from the training samples, the output is going to be wildly off of any intended result. There is no algorithm.
Just a few minutes ago, while copying 63 GB worth of pics and videos from my phone to my laptop, KDE forwarded me the error "File <hard to retain name.jpg> could not be opened. Retry, Ignore, Ignore all, Cancel".
This was around file 7000 out of 15000. The file transfer stopped until I made a choice.
As a user, what am I supposed to do with such a popup?
It seems like a very good example of "Eror Handling Without Purpose" as the article describes, but at user level.
Except that here, the audience is "a plain user who just dragged a folder to make a copy" and none of the four options (or even the act of stopping the file transfer until an answer is chosen) is actually meaningful for the user.
The "Putting It Together" for this scenario should look like: a non-modal section populates with "file <hard to retain name.jpg> failed due to reason; at the end of the file transfer you'll get a list with all the files that failed, and you'll have an option to retry them, navigate to their source position to double-check, and/or ignore".
reply