kevincox

But the problem is that most self-hosted apps don't integrate well with these. For example qBittorrent, Jellyfin, Metabase and many other common self-hosted apps.

NixOS makes it very easy to declaratively configure servers. For example the users config to manage UNIX users: https://nixos.org/manual/nixos/stable/options#opt-users.users

Yet another service to maintain. If the server is crashing you can't log in, so you need backup UNIX users anyways.

I mean it is always better to have more open source. But the point of the multi-hop system is that you don't need to trust the server. Even if the server was open source:

1. You wouldn't know that we are running an unmodified version.
2. If you need to trust the server then someone could compel us to tap it or monitor it.

The open source client is enough to verify this and the security of the whole scheme.

I use NixOS.

Here is the problem with crop quality:

1. Most of the purchase decision is what is observable at the store.
   • Does it look good.
   • What is the price.
   • How is the smell, texture, weight...
2. Some happens at home, and you might remember for next time.
   • How does it taste.
   • How long does it last.
   • Does it make you feel satisfied.
3. It is basically impossible to know how good food was for you.
   • You eat a lot of food and the response is delayed.
   • Even if you have a response you probably don't properly understand your body.
   • In the end most of the "health" of food is just your believes and marketing.

So there is basically no business pressure to have crops be nutritious.

Because these buckets probably don't exist (citation needed on all of these, I don't have access to data from a large online store).

I suspect that this is actually a "good" recommendation in the face of many other facts.

1. Any recommendation has a very low risk of success. Outside of searching contexts (where there is clear intent) I suspect that the chance of a recommendation leading to a purchase is <1%.
2. You usually make more money from bigger sales. So showing a 1% expected $1k GPU is better than showing a 20% expected purchase $20 pair of sunglasses (and I doubt any recommendation has 20% purchase rate outside of clear sources intent).
3. People return things. Return rate is much higher than 1% on many platforms and some good chunk of these will want a similar product to replace the defective/bad/unsuitable one.
   • For Amazon this maybe isn't a good excuse because they should be able to incorporate return information into the recommendations. But even then, lots of people may prefer to order a second one before going through with the return. Maybe they want to do a comparison to be sure that they like the new one more before sending the first back.
4. People do have uses for multiple even for things that wouldn't seem that way at first glance. If I just bought a GPU and am happy with it maybe my partner needs an upgrade (or gets a little jealous). Maybe I will see a similar or identical product recommended and get it for her. Maybe I like my new fridge and also want to replace my second basement fridge with it, or maybe the quietness of the new one made me realize how loud the other one is and I want to get a similar model to replace it.
5. People recommend things to each other. Maybe I just bought a GPU and my buddy is asking if I like it. The next day I see a recommendation for a GPU that I think is a good open for them, I send the link.

Yes, all of these scenarios are unlikely, but I suspect that is actually significantly higher than the baseline, and for the big items that people usually complain about much more profitable. I suspect you see these ads because they work. Not as in they are often right, but that they have higher expected value than other available ads.

Yeah, I can't believe how hard targeting other consoles is for basically no reason. I love this Godot page that accurately showcases the difference:

https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html

Currently, the only console Godot officially supports is Steam Deck (through the official Linux export templates).

The reason other consoles are not officially supported are:

• To develop for consoles, one must be licensed as a company. As an open source project, Godot has no legal structure to provide console ports.
• Console SDKs are secret and covered by non-disclosure agreements. Even if we could get access to them, we could not publish the platform-specific code under an open source license.

Who at these console companies think that making it hard to develop software for them is beneficial? It's not like the SDK APIs are actually technologically interesting in any way (maybe some early consoles were, the last "interesting" hardware is probably the PS2). Even if the APIs were open source (the signatures, not the implementation) every console has DRM to prevent running unsigned games, so it wouldn't allow people to distribute games outside of the console marker's control (other than modded systems).

So to develop for the Steam Deck:

1. Click export.
2. Test a bit.

To develop for Switch (or any other locked-down console):

1. Select a third-party who maintains a Godot port.
2. Negotiate a contract.
   • If this falls through go back to step 1.
3. Integrate your code to their port.
4. Click export.
5. Test a bit.

What it could be (after you register with Nintendo to get access to the SDK download):

1. Download the SDK to whatever location Godot expects it.
2. Click export.
3. Test a bit.

All they need to do is grant an open source license on the API headers. All the rest is done for them and magically they have more games on their platform.

Mullvad is one of the best options if you care about privacy. They take privacy seriously, both on their side and pushing users towards private options. They also support fully anonymous payments. Their price is also incredibly reasonable.

I'm actually working on a VPN product as well. It is a multi-hop system so that we can't track you. But it isn't publicly available yet, so in the meantime I happily recommend Mullvad.

HTTP/1.1 403 UNAUTHORIZED
{
  "error": {
    "status": "UNAUTHORIZED",
    "message": "Unauthorized access",
  },
}

I would separate the status from the HTTP status.

1. The HTTP status is great for reasonable default behaviours from clients.
2. The application status can be used for adding more specific errors. (Is the access token expired, is your account blocked, is your organization blocked)

Even if you don't need the status now, it is nice to have it if you want to add it in the future.

You can use a string or an integer as the status code, string is probably a bit more convenient for easy readability.

The message should be something that could be sent directly to the user, but mostly helpful to developers.

Yeah. I like old school tabs that were clearly attached to the thing that they switched. I definitely prefer the KDE UX here.

I don't think it is that simple. I think that outline is about the "focus". So if I press enter it will activate that tab, if I press tab it will move the focus to the "Entire Screen" tab.

The UX issue is that there are two concepts of focus in this UI. There is "which tab is active" and "what UI element will pressing enter activate". These two are not sufficiently differentiated which leads to a confusing experience.

Or maybe there can just be no keyboard focus indicator by default, but that may be annoying for keyboard power users. But this is generally how it works on the web, you have to press tab once to move keyboard focus to the first interactive element.