Sir, I estimate the project will be completed in 135 days and 11 hours.

I do this by necessity because the medium-sized carts are most popular and they’re usually only available in the parking lot anyway.

How can you tell?

Not exactly. I’m talking specifically about being able to call axum::serve with non-Send futures.

Stop using Brave, people.

I think Kodi is a good choice, but not really sufficient for everything you might want to do IMO.

You could also look into KDE Plasma Bigscreen. It’s still pretty rough around the edges, but I think it aims to do what you want.

I am actually thinking about building something similar with different tech, as I’m not satisfied with any of the existing options. I really want something that’s primarily controlled via a mobile Web interface like the Kore app for Kodi.

I’m not sure what tokio (or axum) can do to avoid the trait bounds. Would it makes sense to provide a “share nothing” runtime implementation that can be injected at startup? I wonder how the intermediate layers (e.g. axum) would indicate that futures are usable by a more generic runtime which may or may not need Send + 'static.

Without some way to write generic code for either runtime, the whole tokio ecosystem would end up bifurcated by this choice of runtime.

Are sockets not files?

Objects may have a single trailing comma.

I just came.

Large ISPs still don’t support it. It’s a fucking travesty.

I think there’s a pretty big overlap of gamers and programmers who use Windows or WSL because they don’t want to have to dual boot.

It’s definitely faster. I have seen measurements from many people showing that Windows is slower compiling Bevy on the same hardware.

Yea I agree. Good UX is a lot of work, and I think FOSS projects rarely prioritize it. Even good documentation is hard to come by. When you write software for your own use case, it’s easy to cut UX corners, because you don’t need your hand held.

And good UX for a programmer might be completely different from good UX for someone that only knows how to use GUIs. E.g. NixOS has amazing UX for programmers, but the code-illiterate would be completely lost.

I believe that the solution is “progressive disclosure”, and it requires a lot of effort. You basically need every interface to have both the “handholding GUI” and the underlying “poweruser config,” and there needs to be a seamless transition between the two.

I actually think we could have an amazing Linux distro for both “normies” and powerusers if this type of UX were the primary focus of developers.

The only correct answer is to be consistent with the code base you’re working in or the language’s conventions. If neither of these conventions exist, then someone has already failed you.

• The Descent
• The VVitch
• The Shining
• The Texas Chainsaw Massacre (1974)
• Audition

How Linux Fanboys see Linux:

So… dev blames skill issues on language? Classic.

EDIT: For the record, I’m not saying the author is bad at Rust. I’m saying they’re bad at making games and balancing tradeoffs. They keep saying that they don’t like rust because they just want to worry about making a game, not fighting the language. And yet, they seem to continually make decisions that favor performance over ergonomics. Then they whine about how the Rust community is supposedly pressuring them to make bad decisions.

Your Git requires a regular flagellation to function properly.

Pays to know how to recover code from the reflog in these cases.

The git push --force is definitely a controversial suggestion, im personally happy with doing that, but I have also personally accidentally force pushed dev/main and seen others do it. Squash on merge is probably a safer habit to have. Also, gitlab and bitbucket both get a bit confused if you forcepush to a branch that is part of a MR.

You can add branch protections that will prevent you from accidental force pushing to main or dev.

IMO when I see a PR with “WIP” commits, I just assume that minimal effort was put into keeping the commits organized, and I squash all commits to review the PR. If I see many meaningful commit messages, I will try reviewing one commit at a time.

When I make a PR, I force push to keep my commits organized. If there are changes I want to make as a result of feedback, and they would create significant churn to rebase all of the patches, then I will apply the feedback in a follow-up commit.