(in my day we were warning people off Avast on account of its similarities to Norton)

This isn't really true in any applicable way though.

Firstly, most people in 2005 were ripping CDs onto their ipods at itunes' 128kbps default - you're still only getting 160kbps today if you're running the free ad-supported Spotify plan but more people are paying for full quality.

More importantly though, the biggest impact on sound quality is noise isolation. People listen to music on the street, in an office bullpen, or public transport: in 2005 your wired sennheissers would need to be overear to deal with that environment in any reasonable manner.The ANC in even the non-pro in-ear airpods is giving you a night-&-day improvement.

Unfortunately, it's hard to classify something as a "rookie mistake" when the developers behind the most revolutionary enterprise tech in the world have accepted it as "by design" & just put a hard-to-find disclaimer about it on one single page of their dense docs.

It certainly does help quell imposters syndrome whenever it creeps up on my though.

Either way though, I would hope it's self-evident to most that taking glaring security holes in a single app (docker) & transforming them into glaring security holes in an entire OS is generally not desirable.

- (a) built-ins (& some libraries) being very verbose to use because they tend to take a "fundamentals of HTTP" approach & not implement shortcuts/common patterns

- (b) libraries commonly falling into the trap of going the opposite direction & ending up with massive scope-creep and/or oversimplified, un-expressive APIs.

This leads to a churn of libraries due to developers yearning for a Goldilocks implementation in between.

Javascript tends to be ahead of other ecosystems in churn due to ease of library publishing, Python's catching up, but overall it's the same pattern in both.

---

Also, one big additional factor is async:

- NodeJS built-ins implemented a callback pattern just before promises took off, & have struggled to upgrade to promises cleanly without breaking backward compat.

- Python's got a similar story with various generations of http library being sync, or relying on different async approaches in confusing ways.

Definitely a domain a million miles from being solved if even English is this bad.

It's entirely possible I'm misreading the spec on clamp() but as far as I understood it, clamp() performs math on a bunch of comma separated fixed values, calc() handles arithmetic operators - this seems to be combining those without a calc invocation, but maybe I misread & overlooked clamp arithmetic operators. Firefox just says it's invalid, no detail on why.

The overall layout is fairly odd & weird - but it's the same in Chrome & Firefox. There is one technical bug with the main body font-size - it uses some invalid syntax (should be invalid in both Chrome & Firefox) & Chrome seems to be accepting it (against spec). The rule:

  font-size: clamp( 1.125rem, 1.125rem + (1.333rem - 1.125rem) * (100dvw - 24rem) / (80rem - 24rem), 1.333rem );

Weird, yes. Broken, I don't think so. Seems to just be a matter of taste.

So it should be the same.

(assuming here that you're deliberately attempting to lose this game).

Either way it was intended as an analogy - being annoyed that a nontechnical user isn't given you everything up front (because they don't know how) is essentially just being annoyed with having to talk to somebody. The solution to that isn't something the nontechnical user should be burdened with, imo, & doing so doesn't tackle the crux if the original issue in any meaningful way.

1. I've experienced both (ai paste slop & ai providing helpful context that would otherwise have been absent) but the former has been a much bigger problem than the purported benefits of the latter

2. before the advent of LLMs, I had fairly strong contrarian opinions on the latter (clueless users asking questions with no detail) that I still hold to this day. A good proxy for my opinions on this is that I think https://nohello.net/ is a crutch for undersocialised (or overworked/near-burnout OR undiagnosed autistic) engineers & should not be normalised. The origin of this sentiment is users entering a quiet IRC room & saying "hello", then leaving & not being around when someone eventually replies: in that context nohello is pragmatic, but taking it beyond that to modern high-frequency realtime chat is an antisocial overstep. Leading with the entire context of your query may have some practical benefits but they're honestly overstated in exchange for killing natural social tendencies towards human dialogue. Similarly, a non-technical user giving you zero info about a problem is an opportunity for conversation & mutual education. It's relationship-building & helps build a foundation for further interactions with this person. It was never a problem in the first place; "solving" it is just another milestone on the road toward de-socialising humanity.

Fellow Fairphone user here & I don't really understand this comment. Why did you buy a Fairphone?

As far as I can understand, the main reason anyone would buy a Fairphone is because they want a fair(er) phone. That "fairness" involves reducing profit-driven exploitation - there's an implicit understanding there that that massively increases supply chain cost, right?

It just feels like you're trying to have your cake & eat it too here. Nobody should be comparing Fairphones to a flagship of any era.

What's remarkable is that it clearly wasn't a priority, which not only sends a clear message to Linux users, but also highlights that their platform choice is questionable if the leading selling point of said platform is something they don't see as an up front priority.

Though of course the third option is that it wasn't an explicit low priority but rather they're simply in disarray organisationally.

I think you've summarised it really well, & it shows:

- the revolutionary promises of AI-driven rapid delivery is nonsense when the delivery bottleneck was always elsewhere - AI is speeding up the part that was never slow

- the fact that - as you point out - it was likely working in Feb but needed a business case gives a good impression of the leadership's approach to Linux support: it's likely such internal case-making will continue to be a factor in future Linux build maintained

1. generally done well by many different UI frameworks

2. generally done better by most popular native UI frameworks than what Electron provides

BUT - those UI frameworks are typically not (very) cross-platform. In that context, Electron provides one of the best unified text-rendering stories of cross-platform options. But definitely far from the best overall.

- Electron based app: Electron is a framework sold on the basis of enabling rapid cross-platform development at the cost of performance.

- Frontier AI company: AI is sold on the basis of enabling rapid development

- App was released in February & took 6 entire months to port to Linux