Linus and Luke of LTT try to daily drive Linux

Declarative config sound super neat. Can you give an example maybe?

There should be no prompt whatsoever which contained the option "destroy my system".

While I get your point that it's a huge UX fail Linus to be able to get to that prompt from the installer GUI, I think that option would always need to be there for the people who need it, and it would always be possible for someone sufficiently determined to blunder their way into the same spot unless the OS completely removes the command line.

Once you get to the command line and start pasting commands from the internet without knowing what they do all bets are off. It's like opening your car's hood and starting to take apart random things.

I think the biggest thing that would help here is for the state of Linux / Pop OS help resources & documentation to get better. There's too many answers or guides that don't adequately explain the impact of technical solutions to common problems.

If you're not a computer nerd, the prompt is very much the end of the line.

This is very much the problem. Computers are ubiquitous, but people who learn to actually use them are deemed 'computer nerds.'

Bring able to recognize what a conflict is, and knowing whether to proceed or not, should be a basic requirement for using the most powerful tool humankind has made to date.

And using apt is very much a standard away to install packages.

But it isn't in this case? POP has a GUI tool to do that, which errored on him. Yes, you can use apt to do it, but that GUI is the default way of doing it. Hell, I'll have you know I learned my linux fu on arch and nowadays I still use the manjaro GUI tool to install stuff. That Pop tool, as far as I can tell, has no option of "destroy my system" - in fact, it failed to install steam, as it noticed things were going in a bad direction. As for whether that prompt should exist, I think that's entirely normal. A system that is so much of a walled garden that it can prevent that is either limited in some ways for expert users (e.g. lacking customization) or is so advanced that it solves the halting problem to figure out whether the command you're trying to run is going to break it or customize it.

Linus merely reproduced what any gamer would do.

That I can agree with 100%. He also got quite unlucky to run into the issue he did.

This is a long one. I originally wrote, "... a long one, sorry," but I'm not. I put a lot of work into this reply and I would appreciate it if you'd at least skim it.

Technical Excuses

I want to get this out of the way first, as a personal note.

But here we are, having a problem with usability and Linux enthusiasts are trying to drown it in technical excuses.

I am really, really sorry I've come across this way, because I've been trying my best to put in pretty much every post something to the effect of, "this is a real and serious bug, and it's a mistake that the Pop!_OS devs should not have been able to make." Here's a smattering of those:

• "it was a bug in the way steam's dependencies were specified".
• "The Pop devs shouldn't have committed a bug"
• "What happened here is that a bug was committed to the Pop repos (bad, a failure on Pop's part)"
• "it's definitely a bug in the Steam package"
• "it should have never been an issue"

I don't know how to more vehemently say this, other than, I guess, this. My opinion of the root cause of this problem is: The Pop!_OS team at System76 fucked up in pushing a broken version of the Steam package to the Pop!_OS repository. My recommendation for remediation is: They should put a system in place to ensure that package dependencies are verified not to be in conflict with the default system installation, especially for packages with known-weird dependencies like Steam.

I am not trying to make technical excuses - I am trying to explain, technically, what happened. I am not the Pop!_OS team and I do not have the ability to implement remediation for this problem; however, I do have the ability to explain why this is a very unlikely circumstance to happen ever again, which I do believe is true. You said that was at least somewhat useful, and I'm sorry I can't be more helpful.

The question I have for you is: what response would you consider acceptable from me? This is not a gotchya; I want to improve my ability to communicate about issues like this and welcome feedback. As I see it, I had four options.

• Say nothing. As someone who uses Linux on the desktop for work and play, and has for over half my life, this feels irresponsible in a thread full of incorrect (reasonable, but incorrect!) assumptions.
• Say, "Yeah, that sucks. This bug is good evidence that non-technical users should not use free desktops." I don't believe that.
• Say, "This is Just The Way It Is. Deal with it." That's condescending, content-free, and also not what I believe.
• Explain the technical nature of the bug and try to communicate why it is unlikely to recur. This is what I did.

Is there an option I'm missing? Did I not execute option four well?

That aside, let's move on to what seems to be to be the core point of this reply.

The Utter Refusal to Learn

You say that you "consider this a psychological issue" and that the "missing concept is actually looking at non-Linux-users' experience trying to use the platform and working backwards from there." You go on to say that "Sitting down with 100 non-techy users and watching them struggle, taking notes, trying to find problem patterns [...] could improve so many first impressions and bring people in."

It sounds to me - and tell me if I'm wrong - like you don't think this kind of work has been done on any Linux-based free desktop; you even say that"apparently no one in the history of Linux distros has ever attempted it," where I believe "it" = "starting with implementing goals like...".

That is simply untrue. Many projects and organizations are involved in building the modern free desktop ecosystem, and almost all of them have been working towards this goal for years.

One of the most common criticisms of the GNOME desktop, which Pop!_OS uses, is that it keeps removing features that power users like in order to make things simpler for new users! One of the GNOME project's stated goals with the GNOME Shell project, a huge undertaking that has defined the project for over a decade (since 2008), is to:

• Apply the lessons of the past and present. We have a real opportunity with GNOME 3. We said up front that we are going to do a new GNOME, clean the slate, re-evaluate what it is we are trying to do, what a desktop is, what a personal computer is and what it should be offering.

They broke with convention and angered many longtime users in order to, among other things, "support a range of abilities from beginner to advanced - while optimizing for intermediates. Be safe and forgiving, flexible and smart. Reduce complexity and strive for transparency."

In order to do that, they heavily engaged with the community of existing users, conducted user research, and compiled hundreds of pages of work on usability and user testing.

Ubuntu, the operating system project which first moved desktop Linux towards the mainstream, has been doing formal usability studies since at least 2008.

On a broader scale, various respected bloggers and personalities have written at great length about how to improve the usability of the ecosystem at various points in time. An example, part 1 of a 4 part series.

Overall, to be frank, it sounds like you think people have just up and decided they don't care about this, when in fact, nothing could be further from the truth.

One Hundred Thousand Hours of Engineering Time

The statement "It's maybe 100,000 hours of work, which is absolutely peanuts in the grand scheme of things" really struck a nerve with me, because I think you may overestimate the resources available to projects like this.

Just to ballpark, in my first engineering job out of college, I made $75,000 a year. That comes out to about $37.50 an hour, and is, frankly, pitiful for the current US tech industry. Even if everyone being paid to work on these projects was doing so at this extremely low rate, you're asking for a collective commitment of almost $4 million just for engineering time, leaving aside the many other complexities of running a gigantic software project.

The GNOME foundation's total income for the 2019-2020 year was $915,646, according to their report; for 2020, it was about $10,000 more. The vast majority is spent on engineering, but they also need to run conferences (GUADEC is, every year, a huge boon for bugfixes in almost every project under the GNOME umbrella), events to help recruit new volunteers, and internships to train new contributors. There are also administrative and systems expenses, which are non-negotiable and pretty trivial; I suggest you look at the report.

That's one of the biggest contributors to open source in the world. You're asking them to spend, at an extremely conservative estimate, four years' income of their entire organization on a single goal, essentially pausing all paid development of bugfixes, security patches, and their existing roadmap. No, I haven't factored Canonical and System76 into this, but remember that this is a very conservative estimate of cost. I also haven't factored Red Hat and other server-focused companies in because they have no real incentive to improve desktop Linux, and only occasionally do so except by submitting kernel patches (good, but irrelevant here) and funding GNOME.

So yeah, you're right that "[100,000 hours of eng. time] is absolutely peanuts in the grand scheme of things," but this isn't the grand scheme of things. This is a cost-constrained, pluralistic effort that, despite everything, has managed to make a competent desktop operating system, supporting hardware whose manufacturers are often actively hostile to its existence.

Conclusion

You end with the following, which I agree with in a sense:

maybe they all tried and failed miserably and it's impossible in a FOSS project? I doubt that because there absolutely are examples of this being done much, much better (I'm primarily thinking of Firefox).

Firefox, LibreOffice, Krita, Open Broadcaster Software (OBS), Blender... all of these are projects whose surface area, except perhaps Firefox, is far smaller than an entire operating system supporting most desktop and laptop computers (even Apple doesn't do that!), and whose supporting foundations have far more money than do the folks working on the core of the GUI experience.

If you want the free desktop to be as polished as the best open source software out there while also remaining truly free, accessible, and with features and hardware support on par with commercial offerings, I suggest donating some money to the GNOME foundation.

Otherwise, I would really appreciate it if you would look into whether people are actually trying to improve their software before talking about being so incredibly hostile towards that effort. Coming out with statements like "an utter refusal to learn" and "they all tried and failed miserably", with no evidence or effort to actually investigate that claim, is really disrespectful. People ask my why I get so heated in discussions about this, and that kind of language is why.

FIN

An Aside on Volunteer Labor

I have not factored in, here, volunteer labor. It's worth noting that the person who caught the issue Linus ran into was a volunteer. However, for the kind of focused user testing and UX design you're talking about, I don't think it's fair to assume that volunteers should bear that burden. People who work on stuff for free are going to work on things that impact them and their friends, or things they're technically interested in; this is good, because it means they're intrinsically motivated, but it does mean we can't tell them what to work on unless they ask.

So, perhaps you can say that some of the cost I talk about could be cut by relying on volunteers. That's probably true. But it's not something the people I assume you're aiming this message at - the professional maintainers - can control beyond lowering the barriers to contribution, which they already spend a lot of time and money on.

These are two incompatible goals — which is totally OK! Not everything has to be for everyone.

For example something like MacOS or Windows might start with a set of high level goals for software installation, example: installing software should never break a users system.

Linux starts with a lower level goal: provide users a method to install packages which may have dependencies and possibly conflict with other packages.

Of course you can build abstractions on top of that to make things more user friendly but unless you prevent people from using the package manager you’re not going to stop people from the possibility of borking their system.