mathstuf

Neither of these updates explained what happened or what the fix was.

"Bug fixes and performance improvements "

Even worse than the "reformat" commit message that your bisect landed on.

Heh…I once was in a state-level coding event (it was a small portion of a larger competition) where half of the test was turning in code on a CD during the competition, with the written half during the event. My CD was deemed unusable for whatever reason (it had worked on XP and Fedora 6 or 7 at home) and didn't count towards my score. I still got second in the event. I declined to continue because I couldn't trust that the judges would be able judge my submission fairly and that with half of my score missing I still got second that I didn't need to prove anything else at the cost of more after-school practice hours and wrecking my perfect attendance record during my senior year to travel to nationals.

There are a number of utilities for this. I use jai: https://jai.scs.stanford.edu/ but also have seen nono: https://github.com/always-further/nono smolvm: https://github.com/smol-machines/smolvm zerobox https://github.com/afshinm/zerobox and matchlock https://github.com/jingkaihe/matchlock

They all have pros and cons. Pick the one that suits you best. Then you're also agent harness flexible (I use opencode).

FD: I am a CMake developer.

Yes, config packages are better. But I think doing find_package everywhere is better. Assuming you install an SDK for others to use your project. If you're a "product", vendor away. The issue comes when you want to vendor X and Y and both vendor Z independently. Then you're stuck de-vendoring at least one and figuring out how to provide it yourself internally. IMO, better to just let Z make its own install tree and find it as a package from there.

One can write good Find modules, but there is some "taste" involved. I wish we had more good examples to use as templates.

1) There could probably be tax credits or deductions for SWEs who 'volunteer' their time to work on these projects.

Why exclusive to SWEs? They tend to be more time-restricted than financial-restricted (assuming the "SWE" comes from a job description). I'd be more interested in making sure that those with less well-paying jobs are able to access such benefits rather than stacking it onto those already (probably) making 6-figures.

Of course, the problems arise in the details. Define "volunteer": if $DAYJOB also uses it (in a way related to my role), is it actually, instead, wage theft? Also, quantifying the benefit is a sticky question. Is maintaining 10k emoji packages on NPM equivalent to volunteer work on libcurl? Could it ever be? Is it volunteer work if it ends up with a bug bounty payday? Google's fuzzing grant incentives?

I had an '89 Cherokee to 235k and sold it for ~60% of my purchse price after 6 years after garages only quoted insanity for the smallest things (Dad is a mechanic, but the commute there for repairs isn't feasible on the regular and apartment living is not conducive to the required garage/tools).

Dad has seen AMC I-6s go 400k before the transmission died and ended its run.

We manage Visual Studio on our CI machines using Ansible. Chocolatey installs the full Visual Studio and then we use the APIs provided to manage components via Ansible. See our action here: https://galaxy.ansible.com/ui/repo/published/kitware/visuals...

I'm sure someone can make a verification parrot too. Why pull yourself up by the bootstraps when you can just strap a rocket engine on your boots instead?

I've thought about making a "word search" and embedding the passphrase in it using a pattern (e.g., a subset of a Knight's tour, a space-filling curve overlay, or some other sampling algorithm).

I agree that the YAML can get out of hand. We use the `extends` keyword to put together jobs from pieces so that details can live in one place and the job bits and graph description can live in another. The way we've done our pipelines are very difficult to do with GHA as we build a DAG (with splits and forks) that are greatly aided by artifacts being integrated into GitLab-CI instead of separate piecemeal actions.

We also need custom runners anyways because macOS and Windows are important and getting those with graphical session access and/or CUDA hardware in the cloud is either $$$$ or severely limited. Even with our setup, we split the build and test phases so that CUDA hardware slots aren't wasted on running compilers. It also lets us test a single build under different environments easily.

So, yeah, I can see fighting with the feature spectrum, but you need to restrict yourself in most other cases with that kind of stuff too. But at least what we do is possible with GitLab-CI.

Why does it always feel so black-and-white? On our projects we do rebases all the time so that topic history is clean. But we merge into the target branch(es) (our merge bot supports merging to old release branches from a single MR). This gives us:

- clean integration branch histories (series of merge commits) - merge commits can contain metadata (topic-level descriptions, trailers for who reviewed, merge request links, test results, etc.) - you can be (pretty) sure that `git bisect --first-parent` will not run into any compilation problems (logical conflicts occur, but are fairly rare; use merge queues to be sure) - none of the "you merged main into your topic" "backwards merges" to deal with too

Merging and rebasing each have their pros and cons, so why not use the pros of each and mitigate a lot of the cons at the same time.

I have tried many times and I have been very unable to make any progress. In The Witness game, I ended up just guessing at the hardest whistle puzzles because remembering high/low order is very difficult at real-time speeds (mostly I can only compare "higher/lower than previous" so something like 2-1-3 is very indistinguishable from 2-1-2). Absolute positioning is even worse. The "end game" tanker puzzle is still unsolved because I don't want to cheat at that one but I have never been able to get the audio part down. I believe this is because my short-term memory "ingests" via audio (100% aphantasia, so no visuals to help out), so trying to "store" more notes erases anything longer than a note or two back (or I remember those notes and miss new notes coming in). Contrast this with Simon-like games (original, Brain Warp, Bop-It, etc.) where I was routinely able to get 12+ because I could "trace" a pattern in the lights/motions and "offload" the audio bits quickly enough to follow along and "compress" the sequence.

In this app, I ended up hunting for the first note and by the time I found it, I couldn't remember "how far" up/down the next note was (and by even 3 notes I often lost the direction from 2 to go). I /could/ figure out the key positions and go from the staff, but that goes through the FACE/EGBDF path of what notes the lines on the staff mean and is 100% non-aural for me. It's also extremely slow.

I also have a horrible time finding melodies and rhythms in music (kind of like Steve Martin in The Jerk, just more…physically coordinated at least). I end up "tapping" out every note and lyric syllable instead of being able to tease anything apart (separate instruments help, but then I lose "the rest"). Rarely was I able to effectively utilize those "song tapper" apps in the 00's to find anything I wanted.

I do remember playing the recorder in class in elementary school and at least "Horse With No Name" on a guitar in…some higher grade (7th? 8th?), but I believe those were very physical-oriented finger memory rather than anything to do with my ear helping out. New songs were basically from-scratch practices rather than being able to build on prior experience.

So while my ear might not be "tin", so to speak, my mind is not well-wired for ir.

Per-display DPI settings. No snooping on input without permission. Awareness of the lock screen (the compositor can know that the lock screen is active and provide alternate keybindings instead of having to configure the lock application as well). Locking is not blocked by context menus being open.

I ran XMonad for 15 years, but recently switched to river and am loving it.

Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).

It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).

I don't think so? But I've never had issues on Linux to need to bother with alternatives (as a terminal dweller, drag and drop is very rare there).

If you have projects that fit within an app, sure. I do not. The only "apps" seen on my machines are terminal windows hosting tmux processes and Firefox. Everything else is ephemeral (mpv, dialogs, rofi, dunst). App-centric behavior is just the wrong axis for this setup.

I'm saying that given what details are there, I think the author is closer to "my" end of the spectrum than one where the question makes sense at all.

As someone who probably has a similar setup on Linux to the author: why do you have 10 windows for an app open?

For me, grouping by app is terrible. Yes, they may all be "Terminal" or "Firefox" windows, but they are for very different things. I'd rather see things grouped by project regardless of "app". But that is what tagging window managers are for :) .

Given that macOS forces that (IMO) braindead tunnel vision paradigm, I think the response should be "Wù".

I know I am weird, but I detest using a MacBook trackpad. However, recently having used Asahi on one, I've found that it is the Apple software that makes it so. I find it really difficult to drag and drop (I would rather open Terminal and standard Unix tools than try anymore) and gestures are way too greedy IMO. Under Linux it is bearable for me (though I still have preferred others slightly for a better texture than the glassy feel).

I wonder if the author is like me in that respect? Not sure I would spend time like this, but I also spent months building my Linux environment from a tty in 2009-2010 (landed on XMonad, finally on River this year after 5 months in GNOME purgatory to force myself to move to Wayland). Last macOS machine I set up, I turned off a bunch of stuff in Settings and was instantly bored because I just didn't want to deal with the window manager at all. It is now my video chat machine because of Dell's "wise" decision to use IPU7 hardware…but I really don't like using it for much else (Asahi reboots are tedious).

They are. If you rewrite history, you get a different hash. You can do some shenanigans with git-replace, but those are usually for stitching history across gaps (like hooking pre-publish history to public release for internal archaeology at least.

What you actually want is a ban on rewriting tags or accepting branch updates to commits that do not have the current commit as an ancestor. These hooks do exist, but are not on by default (beyond the toilet paper protection of needing --force).

You also have to ban deleting branches because otherwise you just delete and push a new one with the same name. Maybe we should store topic branches in repos under refs/topics/ to distinguish integration branches from development/review branches?

That works great for those that only use those tools. I, at least, do not and would appreciate something that doesn't care what editor I use or what forge happens to host the project.

This is truer now that `git bisect --first-parent` exists. But it didn't always. And even then, there are times you find out that there is "prep work" to land your feature. And a PR just to do some deck chair moving that makes a follow-up commit easier is kind of useless. I have done prep work as a separate PR, but this is usually when it is more extensive than the feature and it is worthwhile on its own.

Another instance is a build system rewrite. There was a (short) story of the new system itself and then a commit per module on top of that. It landed as 300+ commits in a single PR. And it got rebased 2-3 times a week to try and keep up as more bits were migrated (and new infra added for things other bits needed). Partial landing would have been useless and "rewrite the build system" would have been utter hell for both me developing and anyone that tries to blame across it if it hadn't been split up at least that much.

Basically, as with many things in software development, there are no black-and-white answers here.

While I also find git-annex more elegant, its cross-platform story is weaker. Note that LFS was originally a collaboration between GitHub and Bitbucket (maybe? Some forge vendor I think). One had the implementation and the other had the name. They met at a Git conference and we have what we have today. My main gripes these days are the woefully inadequate limits GitHub has in place for larger projects. Coupled with the "must have all objects locally to satisfy an arbitrary push", any decently sized developer community will blow the limit fairly quickly.

FD: I have contributed to git-lfs.

Just yesterday I had to edit something on an iPhone. I finally managed to put the cursor at the front to add a word before what was there already. But when I started typing, auto correct (or whatever) put the cursor back at the end of the word. I ended up just removing everything and typing from scratch because figuring out Apple logic behind such a behavior just wasn't on the agenda.

I use that on Android all the time. But I feel I've only gotten it to work once or twice on iPhone. And even then the word boundaries were very "sticky" (IIRC) and precision placement still very difficult.

I also find editing on an iPhone to be an exercise in futility. Is it no longer possible to place a cursor in the middle of a word? I end up having to go to a word boundary and erase from there and retype everything.

The keyboard touch areas also seem offset from Android and I end up one row off too much of the time.

One big benefit of symlinks (really, "not storing it in the deployment") is that my Git repo doesn't have a bunch of hidden files in it because they can appear in the link's path rather than the repo's path. I can also split up files based on "why it exists" rather than "where it lives". For example, I can have the "enable Rust support" group of configurations:

- add Rust things to the list of packages to install - add any Rust-specific configurations for Neovim and `zsh` - bring in any Rust-oriented Neovim plugins

These files all then live next to each other rather than being scatter-shot between Neovim, zsh, and some giant list of packages. Additionally, if I later decide to disable "Rust support" on a machine, the broken symlinks in `$HOME` let me clean up easily without having to actually excise things from the repository.

That said, I have my own system that I built up years ago and it's never been abstracted out for anyone else to use so of course it's going to fit my needs better than anything else.

Also gives me time to plan what I'm going to do once I get there. Or I spot a bug/relevant code snippet along the way.

I use msmtp with a tool from the oauth2-tools repo to do the rotation token dance. Need to register your own app with Google though.

IIRC, you need to run on Apple hardware for a valid SDK license. VM or Asahi or Hackintosh would suffice, but not a VM on a random Linux box. Or did the terms change lately?

At no point has Google came out and stated -why- they're pushing this update in the first place.

The cynic in me recommends that anyone contributing to Google (or really any big tech company) projects to use "bug fixes and performance improvements" or "What's new:" (with an empty body) as commit messages and refuse to update them until we get useful changelogs for app updates.