> Your comment is correct but it's a response to an entirely different and orthogonal point which I did not propose and wouldn't try to.
You're right, I was mixing up threads, I apologize. Your original point seems to be that it's less effort for a Linux distribution to write documentation for shell commands than for them to create a GUI and write the same level of documentation for that GUI, right? If so, I agree, and I understand why a volunteer-driven project would take this route.
However, two points:
First, a properly-designed GUI should require less documentation in the first place.
More importantly, I don't see how this refutes my original point that running shell commands copied from the internet is less efficient, learnable, and secure for end-users than using comparable functionality through a GUI.
Again, I understand why distros take this route, I'm merely pointing out that it is less efficient, learnable, and secure. With respect to the four points in your last post I agree so I'm not sure there's much worth discussing there.
To be clear, I wasn't arguing that a user is less likely to run into issues on Windows (or Mac). The bigger issue is that when they invariably run into an issue it's significantly easier to get the help they need to return their computer to a working state. Between their computer manufacturer, their university/company IT department, friends, relatives, blogs, books, senior citizen tech-support groups, etc there are simply more resources available, and especially more resources that are tailored to a less technical audience.
It's better than it was 20+ years ago (jeez I'm old) when I first tried Linux. Back then you needed to be fairly technical to get it running and even to do basic day-to-day tasks, but now you can use a human-friendly GUI most of the time.
But not 100% the time. And that makes it inaccessible to anyone who doesn't have a Linux expert in their life. Finding a file that got put in a weird place, plugging in USB devices, understanding what version of an application to install (apt? snap? flatpak?), permissions, weird issues after updates, etc. All solvable problems that seem simple to you or me but that would stymie a nontechnical person.
> a large proportion of folks would be switching because a family member was helping them make the move.
Exactly. Linux is fantastic if you have a technical person on speed dial or are interested in investing time and energy becoming a technical person. For the other 90% of the planet it's just not there yet.
> Point-and-click instructions are limited to only 1 desktop...
If a consumer product (computer, phone, TV, microwave, printer, radio, oven, washing machine, etc) requires reading through more than a quick start guide to access the advertised functionality, then it has failed as a consumer product.
> GUI instructions can't be copied and pasted
Training my nontechnical friends and relatives to copy, paste, and execute terminal commands they found on the internet does not strike me as a very good alternative.
Nontechnical folks are fine using a computer until they're not, at which point they need to find someone with more experience or become someone with more experience. Many Windows or Mac users rely on a combination of paid support and friends/family with computer experience. But few people know someone with Linux experience, and fewer still know how to get paid Linux support. That's why every story of a nontechnical person running Linux seems to include a Linux enthusiast friend or family member in the background.
> older people simply aren't interested in or capable of learning new things
I agree that people of all ages can be interested and capable of learning new things, even something as dry as learning how to administer a computer. And Linux is a great option for someone who actually wants to learn more about operating systems.
But the overwhelming majority of people who use a computer use it as a tool to do things, like keep in touch with family members, listen to music, write a book, read the news, look up tutorials, draw, make a webpage, play computer games, etc. Unless you aspire to learn about Linux itself, every second spent dealing with Linux driver issues is a waste that steals time from the actual things you want to do.
In those cases it's absolutely cruel to force someone to dedicate time to learning esoteric technical skills before they're allowed to use their computer. That's why the only people I've evangelized Linux to are people I'm happy to continue to support indefinitely or who are actively interested in learning about Linux itself.
> whether requiring them to copy and paste is actually any more secure than allowing click-to-install...
Agreed. If your operating system requires that you occasionally search for instructions and copy-and-paste executable strings from the internet, that seems less efficient, less learnable, and less secure than any GUI I know of.
Perhaps at some point terminals will bake in an LLM as an intermediary to convert between human-readable instructions and terminal commands, and then we just have to worry about the alignment of those LLMs...
I think it depends on how you define "easier". Once someone learns how to use the requisite terminal commands and does so frequently enough that they do not forget them, I agree that it is significantly faster and more consistent.
> Surely the former would be a better experience for most home PC users?
Our experiences with home PC users must be qualitatively different.
I have trouble getting the PC users I help to remember the name of their web browser or to understand the difference between a webpage and an application. And of the few people I know who might be able to learn how to use the terminal, none have the slightest interest in devoting time to doing so -- they would prefer to use their computer time doing actual work or playing computer games than wasting it learning how to do computer admin tasks more efficiently.
The prospect of teaching anyone but a fraction of a fraction of a percent of PC users to successfully run terminal commands seems so removed from the realm of possibility I have trouble imagining it. Maybe I could see it catching on with an LLM as an intermediary to actually structure the commands?
> for a lot of people that is also a complete dealbreaker for whatever reason
Seems like a perfectly reasonable dealbreaker to me. Terminal commands are a raw UI that is neither intuitive nor discoverable -- someone must either read documentation (man pages, tutorials, blog posts, etc) to learn the behavior and syntax or they must blindly copy strings from a trusted source.
There's a reason most stories of nontechnical people using software like Linux always seem to include an expert friend, family member, or IT person in the background.
While there certainly are some Western hackers who eschew all military applications because of their extreme pacifism, the examples in the article (e.g. pro-Palestinian activists) are not necessarily pacifist. I'd describe them more as out of alignment with their country's current governments, or perhaps actively aligned against them.
And given recent (and not-so-recent) behavior of the US government, I don't think it's irrational for hacker in the US to conclude that their own government presents a greater threat to their freedom than Putin or Xi. (I don't necessarily agree, I just don't think it's an irrational conclusion.)
> any minivan on the market is going to do an acceptable and safe speed
Growing up my folks had an old Winnebago van that took 2+ minutes to hit 60mph which made highway merges a white-knuckle affair, especially uphill. Performance was a criteria they considered when buying their next minivan. Whereas modern minivans all have an acceptable acceleration -- it's still important, it's just no longer one you need to think about.
However, not all modern interfaces provide an acceptable response time, so it's absolutely a valid criteria.
As an example, we switched to a SaaS version of Jira recently and things became about an order of magnitude slower. Performing a search now takes >2000ms, opening a filter dropdown takes ~1500ms, filtering the dropdown contents takes another ~1500ms. The performance makes using it a qualitatively different experience. Whereas people used to make edits live during meetings I've noticed more people just jotting changes down in notebooks or Excel spreadsheets to (hopefully remember to) make the updates after the meeting. Those who do still update it live during meetings often voice frustration or sometimes unintentionally perform an operation twice because there was no feedback that it worked the first time.
Going from ~2000ms to ~200ms per UI operation is an enormous improvement. But past that point there are diminishing returns: from ~200ms to ~20ms is less necessary unless it's a game or drawing tool, and going from 20ms to 2ms is typically overoptimization.
They have renders of what a passenger van variant would look like but my understanding is that this is just aspirational and will not be produced unless the 5-seat truck variant is successful.
Personally I find the increasingly large bulbous noses tacked on to the front of US trucks ridiculous. The fact that these "codpieces" are empty on EVs is such a wild metaphor that it seems like an intentional parody.
I'll grant that the Telo may have gone a little too far in the other direction given that they have issues with the aerodynamic drag of the front wheelwells, but it still looks slightly more sensible than a normal truck.
I have never met anyone who preferred to keep the dome light on all night even at the expense of being able to start the car the next day.
Similarly, I can't think of a use case for preferring that processes keep running all night on a closed, unplugged laptop until the battery dies at which point they all halt anyway. But if someone needs this behavior I suppose there could be an option for it.
> I'm more surprised that any application can prevent sleep _when you close the lid_.
Absolutely. If my options are 1) halt the process when the lid closes or 2) let the battery die heating up the inside of my bag and then the process halts anyway when the laptop dies then please, please let me choose #1!
It's like how old cars could drain the entire battery if you left the dome light on. Why would they allow that?
I've spent many hours debugging my Macbook's erratic insomnia and the only thing I know is that WindowServer is the culprit and it'll likely require a full OS reinstall, which has been on my todo list for months.
The only thing worse than opening my laptop bag to find a hot, dead laptop a couple times a month is the inevitable response of: "Well, you must be doing it wrong, that doesn't happen to me!"
I hear this complaint about designers wanting radical redesigns or chasing trends, but the actual UX designers I've worked with seem to prefer spending time on usability testing, eliminating workflow steps, clarifying hierarchy, making consistent design systems, that sort of thing. True, some of them make things too minimal or rearrange the layout for minimal gain.
However, in my experience the mandate to drastically redesign a product or "make it look more modern" have always come from sales and/or product owners, and in turn they're driven by competitors and customer choices.
If only one company offers jobs in your profession or skill set, that company has a labor monopsony. Back when companies provided lifetime job security and pensions, moving to a remote corporate campus might have been a reasonable tradeoff to consider -- your reduced negotiating leverage would depress your wages but that might have been offset by the lower cost of living (e.g. housing).
But modern skilled workers know how risky it is to put down roots in a place where they only have a couple employment options. So companies struggle to attract talent to remote areas and end up needing to hire in places that already have an established pool of skilled labor, which is typically in the cities and more affluent areas of the state or country.
In this case, the lack of employment options means many of the engineers laid off by Intel will end up needing to uproot their families' lives and move to a new city or state to find a new employer who can to pay for their skills.
> Can someone help me understand when this bifurcation happened
The distinction is as old as art and design. If I had to pick modern moments that articulated it well I'd go with Arts and Crafts followed by Bauhaus.
> solve the right problem for the right people
Solving problems is the core of design and a design can be evaluated on the basis of how well it solves a problem. Whereas art is free to simply exist. Many works have elements of both, but if you hire someone to solve a problem and they believe their job is to make art then you'll both be disappointed.
I'm unsure what motivated the rest of your post though I can feel your frustration. I will say that bureaucracies and processes have been around for centuries, they just shift language every decade or so. There has also always been a tension between the people who Do and the people who Decide but both are necessary for a functional organization.
You're right, I was mixing up threads, I apologize. Your original point seems to be that it's less effort for a Linux distribution to write documentation for shell commands than for them to create a GUI and write the same level of documentation for that GUI, right? If so, I agree, and I understand why a volunteer-driven project would take this route.
However, two points:
First, a properly-designed GUI should require less documentation in the first place.
More importantly, I don't see how this refutes my original point that running shell commands copied from the internet is less efficient, learnable, and secure for end-users than using comparable functionality through a GUI.
Again, I understand why distros take this route, I'm merely pointing out that it is less efficient, learnable, and secure. With respect to the four points in your last post I agree so I'm not sure there's much worth discussing there.