I also self-host email on a Hetzner VPS. I pay about 9 Euros/Month.

I sure hope you’re using that for a lot more than email.

1. Get cheap Hetzner VPS with redundant volume.
2. Get a domain name.
3. Run Stalwart for you mail server.
4. Run Bulwark for your inbox web app.
5. Run Kanidm for an identity provider.
6. Configure these DNS records: MX, SPF, DKIM and DMARC

There are more details, but those are the basics.

My god what an obnoxious website.

So what formal language do you think would be more appropriate than Lean for this purpose?

Then what was your point?

not mathematically complicated but logically complicated

Lean is more than capable of modeling logic.

You could use that to run the TisVlay CLI to automate TV related macros

Nice idea. I may try this out next time I’m tweaking my NixOS configs.

But for speaker bars/stereos, that’s another idea to add to the HDMI-CEC backend.

Yea that definitely sounds interesting. My speakers are connected over optical digital audio cables. I can’t even control them with my TV remote. I’m not sure I will be able to make this work. But I am planning on getting a new TV soon so 🤞

I use Plasma Bigscreen for my HTPC. I can’t speak to development status, but I know that it is functional for me as I use it daily. I use it for two things: moonlight game streaming client and jellyfin client. I can use the KDE Connect android app as a remote, but more often I use a bluetooth game controller or the Jellyfin android app to cast stuff.

It’s basically never locked because I don’t need it to be.

I don’t have an OLED TV yet, so the burn in prevention stuff isn’t useful to me yet. But having things like power and volume control on my phone would be really nice QoL improvements. I currently need to use my TV remote for power and input selection and my speaker remote for volume (though at least Jellyfin has its own volume control too).

Nice! Thanks for sharing!

I’m curious if you’ve used Plasma Bigscreen, what you think of it, and how TisVlay would integrate with it.

the code you have to review hasn’t been thought about

Isn’t that just admitting that the author of the PR has not read the code they’re submitting? If I caught wind of that I would reject the PR on principle without even reading all of it.

If you are competent and using an LLM to generate code you’ll put your name to, that mean reviewing a lot of code that isn’t up to your usual quality, rather than just writing it yourself, which is frankly extreme tedious, demoralising, and mentally exhausting

That’s not been my experience. While there are often multiple iterations of feedback I go through with an LLM before I consider a PR ready, it’s rarely a significant deviation from what I already planned out. Most often it’s just basic code organization that I forgot to specify (especially if the area of code it’s working on was already poorly organized), or tradeoffs I wasn’t even aware of until the code was written. The amount of effort per cycle is usually very small, and I’m able to work on other things in between (like reviewing other peoples’ code).

If you’re not competent, you wont catch any of that, and it’ll either just go to production, or it’ll fall to someone else to review it.

This sounds mostly like a workplace culture problem. It’s always been important to have a high bar on code review to catch poor quality. Not to catch bugs per se, but to catch code that isn’t properly tested.

you’re going to end up flooded with low quality commits from coworkers who’ve either given up or weren’t competent in the first place

Again, that’s a workplace culture problem. You need to either stick to your principles and try to enact change, quit, or go along to get along. I’m sorry if the last option is where you’re at and that does suck.

it’s much harder to train people to good practice when they’re abdicating the thinking to a machine

I totally agree. That’s something each engineering org needs to reckon with, lest they burn out the devs who care about code quality.

Spending your day reviewing code churned out by an LLM, is a soulless and tedious way to spend your life.

Someone has always had to review the code. And the author has always been responsible for their PRs meeting a quality bar. I don’t see how this is any more soulless or tedious than before we had LLMs. Maybe you just never enjoyed reviewing code in the first place, and now you have to do it more?

I think you’re thinking about this in a very negative way when you also have the option to see it as an opportunity. You said yourself that now you’re focused more on design and architecture, and most of your time is spent reviewing code. That sounds like a relatively good place to be, assuming you’re happy with the quality of the code. Now you can spend more time solving new, harder problems that you couldn’t before.

You are correct to point out the distinction between race conditions and data races. Rust only rules out data races.

I don’t know whether the race in question was a data race or not.

I would still wager that Rust code generally has fewer race conditions than C, given that mutable aliasing can be used as symbolic prevention of race conditions, i.e. your &mut T doesn’t necessarily need to hold data; it can represent some domain concept.

aren’t language specific

There are actually languages that guarantee deterministic concurrent execution, and this can rule out larger classes of race conditions than just data races. See the Bloom language and CALM theorem.

It’s been replaced by the overuse of confusing foo's own [implied noun] phrases.

I could attribute the race condition just as much to their use of the C language as to AI.

Right. Removing the wiretaps from your home is cyber abuse now.

deleted by creator

That definitely increases the challenge of writing tests or trusting that they are faithfully representing your production environment.

I could abstract out the reading of the data

I was going to suggest this, and it sounds like that ends up being expensive. It seems like you need some kind of test harness that’s able to emulate your specific hardware while still allowing for testing hooks that don’t impede the tight clock scheduling.

he is comparing a deterministic tool with a non-deterministic tool

Yes, but that’s not the argument Mikina was stating. Linus was never advocating for reading assembly line by line. Linus was using that as a satirical example, not suggesting anyone should actually do that.