> it seems that basic stuff like wifi still doesn't always just work

This is true. I've been using Ubuntu since 2006, but still see issues with

Wifi: Ubuntu 22 didn't work out of the box with a 2014 macbook air

Bluetooth: maddening trying to set "listening" mode instead of headset mode on JBL earphones - it seems to choose randomly every time it connects, and the setting isn't exposed in any UI

Sleep: I don't think I've ever seen sleep/suspend working reliably on a Linux laptop, to the point I don't know the difference between the two. I have one thinkpad which never wakes from sleep, and also never fully shuts down on system shutdown without a long press of the power button.

I accept all this so that I don't have to wait seconds for basic UI things to happen, like switching virtual desktop (osx) and opening the application launcher (windows).

Counterpoint: I've been using enterprise thinkpads for the past 15 years and never had issues with wifi, or suspend. So again, it's about how you choose your hardware so it works with Linux...

I had a Thinkpad T480s that was absolutely perfect with Linux (Mint), although very underpowered, but that was due to Intel CPU.

This year I got a T14s Gen6 AMD as a replacement, and it's essentially unusable on Debian-based distros (Ubuntu, Mint), but works fine with Fedora and with Windows.

On Ubuntu and Mint, X just locks up every 80 seconds or so, and I have to hard-reboot it (or switch ttys and restart X). Nothing in syslog, nothing in dmesg, nothing in X.org.log to show what might be going on.

I've also used enterprise thinkpads for the last 10 years. No wifi issues on those, but sleep and bluetooth issues as described. I have no idea if Windows would have been more reliable.

> huge accretions of complexity for very little payoff

Am I in a minority finding SPAs significantly easier to write and maintain than server-rendered HTML and JS? Or is this point of view merely a reflection of where my experience lay in the 2000s (server-rendered) vs 2020s (SPAs)?

SSR HTML/JS sucks if:

- there is repeated code among pages

- the JS isn't in Typescript

- the JS is still using callbacks

- it's using a JS UI framework (Kendo) that you don't like

- the CSS is a mess

All of which was more common closer to 2000 than 2020 because we didn't have things or didn't know better.

SPAs by default at least helped with repeated code and CSS since code organization and maintainability were one of its main selling points. These days most new projects will use Typescript out of the box too.

I think it's just what you are used to. I think a Spa is easier than server rendered html as well, although server rendering a spa brings its own complications. But the component model à la React is so crucial.

I'm with you brother.

Trying to hold sufficient session state on the server and then doing your work afar is a ridiculously hard problem to keep up. The controller of that distributed system is very far from what it's trying to work. State keeping from afar is not pleasant. Especially when there are little pools of state that are essential on that client, when the illusion being worked to maintain keeps breaking down.

A thick client page, that has the agency there, that can operate & control the local experience, is imo just so clearly a simpler system to build and run. It also often has much better performance characteristics.

Representative state transfer allowing the page to become the operator is simpler. Let the client be it's own thing. Give it tools to get and work that state, to update the remote server.

Sounds scary, sounds complex, is mechanically much simpler.

> 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.

> you have to make a brand new branch for your next PR

Is there overhead to creating a branch?

Run them on different ports?

Yep, for now that's how we do it! We're looking into remote sandboxes and tunneling soon though :)

My browser has a half-inch white bar at the bottom constantly, presumably because of this setting.

Cannot reproduce on 26.2 with either Safari or Chrome with the setting on. That would infuriate me.

When first scrolling, the bottom page controls disappear. But they leave their container blocking the page content.

Animations are also a way to explain causal relationships between interactions and their results, and to help build mental models of software behaviour.

Being related to neither software behavior nor the structure of the underlying problem, animations tend to obscure the causal relationships and make it harder for user to build a correct mental model.

I see where you're coming from: animations are overused and even when they make sense they are made too slow and flashy (because otherwise how would the implementors feel like they did something if it's barely noticeable?)

Animations are like bass in music: most people notice them only when they're missing or bad.

> I don't want to commit something that doesn't build.

This is a really interesting perspective. Personally I commit code that will fail the build multiple times per day. I only care that something builds at the point it gets merged to master.

so basically, not adhering to atomic commits. That's fine if it's a deliberate choice, but some people like me think commits should stand on their own.

(i'm assuming your are not squashing when merging, else it's pretty much the same workflow)

> i'm assuming your are not squashing when merging, else it's pretty much the same workflow

I AM squashing before merging. Pre-commit hooks run on any commit on any branch, AFAIK. In any serious repo I'd never be committing to master directly.

Honestly, i find that a really weird view. I use (Local) commits for work in progress. I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git.

What do you do when you are working on something and are forced to switch to working on something else in the middle of it?

I'm merely the grandparent commenter, not the one you replied to directly, but I can tell you what I do for checkpointing some exploratory work or "I'll continue this next week".

I usually put it on a branch, even if this project otherwise does all its development on the main branch. And I commit it without running precommits, and with a commit message prefix "WIP: ". If it's on a branch you can even push it to not lose work if your local machine breaks/is stolen.

When it's time to get it into the main branch I rebase to squash commits into working ones.

Now, if my final commit history of say 3 commits all actually build at each commit? For personal projects, no. Diminishing returns. But in a collaborative environment: How fun will it be for future you, or your team mates, to run bisect if half the commits don't even build?

I have this workflow because it's so easy to add a feature, breaking 3 tests, to be fixed later. And formatting is bad. And now I add another change, and I just keep digging and one can end up in a "oh no, how did I end up here?" state where different binaries in the tree need to be synced to different commits to even build.

> I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git.

WIP commits is hardly the only benefit of git or other DVCS over things like subversion.

> What do you do when you are working on something and are forced to switch to working on something else in the middle of it?

`git stash` is always an option :) but even if you want to commit it, you can always undo (or `--amend`) the commit when you get back to working. I personally am also a big fan of `git rebase -i` and all the things it allows me to fix up in the history before merging (rebasing) in to the main branch.

All of those are things i would refer to as making a commit :)

I interpreted the parents post as: as long as my combination of commits results in something working before getting merged, it's fine.

Local wip commits didn't come to mind at all

Well we are in a discussion about pre-commit hooks. Pre-commit hooks run on local wip commits.

Well, unless you inhibit them with `-n`. Which I would for WIP commits.

Then what’s the point? Just leave them off and run the tests when you want to run them.

Because 99% of my commits are not WIP commits. So I almost always want to run them.

Hell, even most WIP commits will pass the tests (e.g. tests are not yet added for the new code), so I'd run them then too.

Some people write tests first.

And commit in such that the final timeline has broken tests for half of commits?

Sounds like an awful way to live your life.

No, we're not talking about the final timeline. That is finalised when (or if) code is merged to the mainline. We're talking about what happens when the command "git commit" is executed.

Ok, if you're talking about just WIP commits that will be squashed and will never be part of mainline, then shrug.

For me that's a tiny proportion of commits. I'd rather avoid taking a whole finished feature branch and then spend more time cleaning up a sloppy commit history.

Sure, sometimes it's correct to squash, but for nontrivial changes I go with https://github.com/google/eng-practices/blob/master/review/d...

> e.g. if it contains a private key file included by mistake

Thanks - this is the first example of a pre-commit hook that I can see value in.

Remember that such key will be copied into the repository on `git add` already and will stay there until garbage collected.

Thanks, good to keep in mind. Although presumably that means it's in my local repository. And it would have already been in my local filesystem anyway.

> with git, you can even make anything that happens on the dev machines mandatory

s/can/can't?

You can an an enterprise environment when following SOPs are mandatory due to cybersecurity and infrastructure requirements.

Yes, indeed.