Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)WO
Posts
13
Comments
78
Joined
2 yr. ago

  • That's not how you should mix tabs and spaces for alignment. You use the same number of tabs as the previous line, and then fill the remaining width with spaces. That way, when you change tab width, the alignment spaces will always start in the same column as the line they're aligning to, regardless of the tab width.

  • Peanuts and dairy are usually possible to spot without checking the ingredients list, and they serve a distinct culinary purpose. They have valid reasons to exist, and are fairly simple, if a little annoying, to avoid.

    HFCS does not serve a distinct culinary purpose (it's pretty much just sugar but it benefits from corn subsidies), and is impossible to identify without careful scrutiny because it's included in all sorts of foods that it has no business being in. The (purely financial) benefit it provides is far outweighed by its harm to public health.

  • He can eat corn just fine, but HFCS gives him a migraine. I'm not sure why, but it happens consistently even when we don't notice it on the ingredients list at first so it's not psychosomatic or anything like that.

  • My big killer feature for Linux phones is running Wayland/X11 apps mostly unmodified, if AOSP added support for that I wouldn't be too disappointed about sticking with it. I've tried to make android apps before, but doing things the Android Way™ basically requires you to use java and their bespoke UI primitives, and it always makes me wish I could just use the tools I'm already used to.

    Being able to have intricate control over my phone is nice, but I'd rather do it with a KDE-like settings maze than a terminal because of how tiny the screen is, and if I'm doing something serious that would require a terminal I would rather do it at my desk.

    I definitely think the Android ecosystem has some serious problems, but I already run a custom ROM without Google Play Services installed so I'm fairly well-insulated from that. I do plan on installing a mobile Linux system on my old phone to experiment, but I doubt it will become my system of choice.

  • You need to use root or pass through some other access control mechanism to control network interfaces or audio devices on Linux too, Android's access control mechanism for those things just isn't built with shell scripting in mind because using a terminal on a phone is a pain...

  • Would be an excellent change if they replaced it with a chronological timeline, but we all know they won't do that even though their backend already generates RSS feeds and it would barely take any effort to integrate with the frontend

  • Some games use a "trust" system based on human reviews of your gameplay that affects how you are matched with other players, but there isn't a respectful way to force people to use just one account so that the trust score can follow the person. The best way I can think is to tie the purchase of the game to that account, which many services do, but that breaks the used games market...

  • There's a concept I call "rule zero of cybersecurity": "the user can and will exploit trust you place in them or anything they can touch."

    You can make it more difficult to exploit the trust you put in the user by hiding it behind obfuscation, but ultimately the user can desolder your secure enclave, reverse engineer your anti-tampering measures, and falsify any check your program wants to do, if it happens on their computer.

    Client-side anticheat on Windows doesn't "work" in the pure sense either, it's just enough of a pain to bypass that most people don't because you can't recompile the kernel to change how it behaves. On Linux, it's easier to take advantage of the fact that perfect client-side anticheat is fundamentally impossible.

    Same with device attestation, DRM, and other client-side verification measures: they're doomed to be in an endless back-and-forth because what they're trying to do is fundamentally incompatible with reality.

    The correct choice for anti-cheat is to detect cheaters like humans do: watch a player's actions as they are received by the server, and use your knowledge of typical player patterns to detect if the player is cheating. Your server's knowledge of the network messages coming from the user's computer is the only thing you can trust (because it exists on hardware you control), so you should make your decision by analyzing that.

  • I think if they were categories instead of reverse domain names, it would at least be easier to remember. As it is now they're mostly just meaningless, and I think it would be better if you could refer to apps with only the last part as long as it wouldn't create a name collision.

  • Flatpak and AppImage are trying to make that easier, since they both work the same on pretty much any distro, but not everything is packaged that way yet.

    Flatpak is closer to the typical package manager model, where you install things from a graphical store or the command line, while AppImages are self-contained binaries that you download from the developer and run as-is without installing.

    Snaps also exist, but they don't work well outside of Ubuntu and its descendants...