mixedCase

.envs generally aren't full blown shell, so you don't have `export` available. With that said, I keep a shell function in my .zshrc which, when given a .env file (or when not given one, assuming $PWD/.env) will set -a, source it and set +a, which loads everything into the environment.

A "runtime type system" does, meaning something like io-ts or zod.

It also allows statically typing and transforming env strings into much more useful and complex structures.

You can easily have both .env and types. On any TypeScript project you can just pass your process.env through an io-ts, zod or similar library and keep it in a side-effectful module which validates on first import and keeps it globally available.

Do they work in Brave? Still Blink, but removes Google's direct control of your browser and many of its misfeatures/malware.

That's not really the point. The point is to take away control from Google's user-hostile decision making, and that's a good chunk of the value proposition of Brave as a fork/patchset.

Convince everyone you know to switch browsers. Tell them the truth we all know: If people keep using Google Chrome, they'll take away ad blocking, they'll block you from copy-pasting, taking screenshots, anything you know the usual bastards have tried or you can imagine will try to restrict a device from doing to try to "extract value out of the user".

Firefox is the most obvious alternative, and for those who prefer a Chromium base: Brave, Iridium and ungoogled-chromium, in order of how much functionality has been stripped away from least to most, are open source, privacy-focused solutions.

Don't modern keyless fobs use something akin to TOTPs? A well kept clock can easily prevent relay attacks.

It's just what the human palate does. It adapts to circumstance. Skip sugar and sweet stuff for a few months and when you try it again everything tastes much sweeter than before. Same with salt. Same with acidity. And surely other things I haven't tried and corroborated with peers.

In that particular case, Reddit has a usable browser interface that works on desktop (old.reddit.com) but it doesn't have a mobile equivalent.

Alternatively, io-ts is more performant and has been around for a while longer. Although it does have a more functional interface.

It's not a problem of federation, it's a problem with ActivityPub or at least the networks built on it. The current system is echo-chambery in nature because your instance owner does not only control your own speech being hosted there, but also who you're allowed to read from your feed and who you're allowed to talk to.

It may be intentional, it may be due to a byproduct of how the federation details are implemented, but regardless of how it came to be the end result is an undesirable protocol for discourse and as far as I'm concerned, not worth the effort compared to just switching to scraping Reddit until a worthwhile federated social network appears.

XDG portals are just APIs that applications can implement and use.

Regardless, do you not trust the applications that you run natively?

The problem is that when you go beyond DDL, or you want to execute backwards incompatible DDL changes, you can no longer make these migrations declaratively.

An RO filter is not accesible to the majority of the population.

The difference in real world performance between web servers written in things like Python or Ruby to those written in Go, C# or even lower-level languages like Rust would indicate that's an over-estimation of how much IO dominates total runtime, even if it is by far the slowest part.

As you said it: Of course, that's you. But not everyone walks the same path towards robust coding, let alone coding.

You may have to do some bindings yourself, I remember once looking to try out a libadwaita widget and it wasn't fully supported in the available bindings, don't know about the full library of gtk4-specific widgets.

As for feature complete, depends on your definition. It's on 0.6 and major changes do arrive and updates do break user code, but you certainly can write apps with it.

Relm4 is actually based on gtk-rs, and you will be using gtk-rs widgets all the time.

I have to say however that despite heroic efforts by the authors, it doesn't really feel as nice as the "real" Elm architecture precisely because of the imperative focus of gtk-rs' API, the nature of Rust's memory management system, and depending on what you're doing you may feel forced far too often to drop from fantasy land to reap the benefits of the abstraction.

I'd still consider it next time I tackle a native app, but having tried Slint for writing simple UIs and having read some iced code, I think I'd only go for it if I'm really going for the Gtk native look and ecosystem.

> Testability, tooling and the open-source ecosystem and either bad or non-existent

If you're properly testing the code in your application that exercises persistence, that means your test harness runs a real database like the one you're running in production and thus you can also write the database logic tests using your own application's testing facilities.

Of the things you listed, "the database sends e-mail" is the only one where I'd think you'd have to change the code at all, and have the database go through a mockable middle-man so that it becomes testable; but everything else can be comfortably tested from a test suite that is able to talk to a real database.

On the desktop, newer kernel usually means more stable, although it becomes less true as the hardware running it ages.

Yep, even the Lelit Bianca which is a dual-boiler and has both flow control and a pressure knob is still cheaper than the cheapest Decent despite the much more robust build.

> Inflation is also good for those that own assets as their relative value to dollar increases.

That's not "good", it's just less bad, because as soon as they want to turn those assets liquid they run into the same problem. Their assets are not gaining value, they're just not losing it.

Using Rust and esp-idf you can simply call the standard library threading facilities if you want to do concurrency, and it's all handled in the background by FreeRTOS for you.

TypeScript is not a feature of JavaScript, and the ability to have single-threaded IO event loops is far, far, far from something modern, unique or remarkable about a language, the fact that it's limited to single-threads actually makes it something you really do not want to bring up as a "pro" but rather as "it's something you'll have to keep in mind".

If you're willing to consider a piece of advice, even the most complex rude goldberg-style codebases will yield to the program entry point. From there, you can start pulling at the wool and process it one knot a time.

It's tedious, slow work, but you can use note-taking, the REPL, tests (reading, if any, but also writing them), diagrams or any other tool for creating mental models until you manage it.

You could've shortened that to: You're paying for the cloud integration and the management software*

Most paid software has no relationship between its price and business costs. That's what makes software special from the business perspective.

How does your comment explain that smaller communities are doomed to failure? It seems you disagreed and went on a very wild tangent far away from the idea the GP brought up, and in fact may only reinforce it.

> Yeah, I know about LLAMA, but as I understand - it's not exactly legal to use and share it.

For anyone keeping track, this is when you update your cyberpunk dystopia checklist to mark off "hackers are running illegal AIs to compete with corporations".

The thing you're laughing at is how you deal with coffee grinders that spit out clumpy coffee. If you don't break the clumps, the high pressure water from an espresso machine will distribute unevenly throughout the puck (choosing to go through the path of least resistance) and will be the difference between drinking a notoriously-finnicky-to-get-right light roast and battery acid.

It's just physics, and something you can check for yourself in 5 minutes or by asking any chemical/food engineer who knows the basics of extraction.

The GP is referring to the political costs of changing bad code, not the technical challenges which are almost always manageable by any experienced programmer. Egos, however.