asoneth

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.

I'm not saying local first will help or hinder UI latency, merely that UI latency is indeed a valid evaluation criteria for software.

Western strain of extreme pacifism

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.

I suppose there's no accounting for taste.

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!"

It is a genuine concern and should be addressed.

No disagreement, but does the comment meaningfully contribute to the discussion about this particular project?

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.

the designer is to dream and your job is to build it

You may be thinking of an artist. A designer's job is to understand and solve user problems.

(FYI this is coming from a designer, not an engineer.)

Similar to software developers, there's a difference between meeting a user need with with established patterns and exploring novel ones.

The vast majority of consumer and enterprise products ought to be done with established design patterns. Figma is fine for this.

Whereas exploratory design is about coming up with novel patterns. Most of this work ends up being interesting but not particularly practical, and even when someone comes up with something great it's often not yet clear how and where it should be applied. In my experience only a few companies actually pull this off and the rest would be better off following existing conventions. Also in my experience, people who do exploratory design have a wider skillset and use a much broader and more flexible set of tools like pen and paper, physical prototypes, 3d modeling, computer graphics, video production, software development, etc.

The challenge has been that many designers are hired for the former but would prefer to do the latter.

I agree with many of your statements but draw the opposite conclusion.

HTML and CSS are expressive, have a vast selection of libraries and tools, and can actually result in shippable code. Designers and front-end devs should learn and use it.

But I don't see the point in creating a design tool unless it's meaningfully simpler than HTML/CSS. I reach for Figma when I need to quickly mock up a dozen iterations using our design system and fancy rectangles. It's fast enough that I can make mockups in realtime during discussions with developers and subject matter experts. But if I'm actually going to take the time to set constraints to make things flex properly or make a real table then why not use HTML and CSS directly?

Employers, you can't have it both ways.

Exactly. Though you can learn a lot about an employer by how it has conducted layoffs. Did they cut profits and management salaries and attempt to reassign people first? Did they provide generous payouts to laid off employees?

If the answer to any of these questions is no then they're not worth committing to.

you clearly arent an OS engineer either.

Correct, though I do regularly deal with the same class of assumption, where folks suggest that if I just hired a couple people to work on X, Y, or Z that would be well worth the money. The statement seems to come from a place of hope, a belief that there is a simple solution just waiting for someone to point it out, as opposed to something that is very hard or simply impractical.

But it's just not realistic to believe that the only thing preventing a niche laptop manufacturer from matching the battery efficiency of a vertically-integrated product backed by $30+ billion a year in R&D is a couple OS developers. Such a belief can also be demoralizing if every hard-won incremental improvement to Linux power efficiency is judged against such unrealistic expectations.

(I believe that someday we will have lightweight Linux laptops with 22+ hour batteries, but I also believe that by that point Apple will have shifted the goalposts again and people will continue to be dissatisfied.)

The rave reviews alone would be free marketing worth well above the money invested in the software engineers.

Whether it's worth it depends on how much it costs to improve efficiency, and how many more laptops they need to sell at a higher price to recoup those costs.

For background, the AMD Framework 13's 61Wh battery supposedly gets ~9 hours[1] (~6.8Wh per hour), the System 76 14" Lemur Pro's 73Wh battery claims up to 14h [2] (~5.2Wh per hour), the MacBook Pro M4s 72Wh battery claims up to 22h [3] (~3.3Wh per hour).

I am skeptical anyone can get close to Macbook levels of efficiency without soldering components, designing new chips, and spending close to their ~$31 billion in R&D. But let's say we shoot for 4Wh per hour to get us in the 15-18 hour range.

If you could achieve such an improvement with a couple software folks and you can amortize it over a million laptops that might add less than ten bucks per laptop. That'd be great!

Personally I am skeptical it's anywhere close to that easy, and I'm skeptical that these niche manufacturers are selling a million laptops a year. I think it's much more likely that meaningfully improving efficiency would require making each laptop significantly more expensive.

would pay an extra money per month for Apple level battery life ... I would gladly pay much more above and beyond a macbook pro

But would you pay an extra several hundred dollars for a Framework or System 76 laptop if other Linux laptops received the same efficiency benefits without needing to increase their costs to cover developer salaries? Apple can afford to spend billions improving efficiency because they can amortize that across many more laptops and because they can capture most of the benefit of their research. (And because for several decades they had loyal customers who paid an extra couple hundred bucks per laptop even when they didn't have better efficiency.)

Something like this would be myself and many other peoples literal dream computers and withing a year or two's time almost any Linux user would be on System76 laptops, guaranteed

If we're dreaming, why stop there? If System 76 produced a $10 laptop that can be powered by nothing but sunshine they'd take over the world! But realistically, I think the best we're going to get in the foreseeable future is slow, incremental efficiency improvements that lag a generation or two behind Apple.

(A simpler way Framework or S76 could increase battery life to the ~15-19h range would be to bump up to a 99Wh battery which probably costs on the order of a hundred bucks for the larger battery and chassis, though it would also make the laptop thicker and heavier.)

[1] https://www.tomshardware.com/laptops/ultrabooks-ultraportabl... (I don't see a manufacturer claimed range) [2] https://system76.com/laptops/lemp13/configure [3] https://support.apple.com/en-us/121553

Sure, it totally depends on specifics! Only Framework knows how many mainboards they sell per year and can make an educated guess at how many of them end up running Linux.

Also, note that Framework already employs at least one person[1] working full time on Linux compatibility and support, so at least some of the low-hanging fruit may have already been picked. I'm sure they could spend an additional $300k, $3M, $30M, or more on improving Linux efficiency. I can't estimate what the benefit would be at each of those levels, nor do I know what the price impact would be, nor the sales impact. I don't know what they currently spend on Linux support except that it's at least one FTE.

We don't have enough information to answer or even meaningfully estimate most of these questions. I'm not saying they're making good decisions or bad decisions with respect to Linux support, I'm just saying neither of us have enough information to know.

[1] https://matthartley.com who was previously at System 76

Is it pound foolish, or just a rational business decision?

Let's say they ship 100k laptops per year. Let's say they could meaningfully improve battery life with a team of half-dozen excellent software engineers, which would cost on the order of a few million a year. For the sake of argument, let's say ~$3M/yr. That increases the price per laptop by ~$30 on average. That's a premium I'd pay for improved efficiency, but judging by the comments here and elsewhere, the premium they're already charging above the raw component prices seems to be at the upper end of what most people are willing to pay.

It's fiendishly difficult to become the next Apple, Tesla, Nintendo, or Valve with thick enough margins on your hardware (or services) to afford excellent software engineering teams, so it makes sense that so few hardware companies attempt it, and many who try eventually give up.

too much risk to make back on users who actually sign up to your store and buy books vs ones that put the gift in the closet, clearance models, losing to a more popular store

I definitely agree that selling hardware at cost (or at a loss) in the hopes of turning a profit off of content sales is an extremely risky strategy. Many companies try that approach, few succeed.

But if you price it like a typical consumer product and sell it for ~1.5 * BOM (i.e. ~$50 retail price on $35 BOM) then you don't need anyone to buy books because you can survive off the profit from the hardware alone. And because I believe that a $50 ereader would sell well, I don't know why they are not more common if it really is possible to build and assemble a mass-market ereader with a $35 BOM as the prior poster claimed.

Well the pricest component is the screen, and that's under patent.

I think rising consumer expectations soak up a lot of that -- you could make the main board and other components a third the price if you're satisfied with mid-2000s specs e.g. 200MB storage, slow page turns, bundled radios, no touchscreen, no PDF support, etc.

At some point the raw materials cost (which generally aren't getting much cheaper) becomes a major factor and that's harder to cut without a new approach.

Eink screen aside, it may be that we're just nearing the limits with current manufacturing approaches and that the next leap requires a wildly different approach.