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/)CB
Posts
5
Comments
505
Joined
2 yr. ago

  • OP here! People are rightfully pointing out that this can be compressed further.

    My challenge to you: Implement a compressed representation along with the get_cell and set_cell methods, without resorting to lookup tables!

    Also, check out Alejandra's blog at https://goose.love/!

    (And yeah, you need 12 or 13 bits, not 10, if you don't want to eliminate symmetries.)

  • Worse.

    Without tips, the employer pays $7.50/hr. That's not enough to live on, especially since food service workers are almost universally working part time.

    With tips, the employer pays $2.50/hr, but tips can make up the difference to be somewhat more reasonable.

    To abolish tipping, we need to:

    1. Abolish servers' wage ($2.50) / pay full minimum wage.
    2. Double the minimum wage to $15/hr.
  • (Also, you can change the default editor visudo uses, but I don't remember the command because I won't be changing it until I get a grip on vim and can make a decision about which editor I want to use.)

    It just uses your preferred editor, which you set with the EDITOR environment variable. In fact, any program that opens an editor should use this to determine the user's preference.

    I set mine to VS Code:

     
            export EDITOR="code -nw"
    
    
      

    Examples of programs that use this variable include visudo, crontab -e, and git commit.

  • After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs. One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today.

    From https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq

  • After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs. One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today.

    From https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq

  • After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs. One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today.

    From https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq

  • Nothing. They're mostly the same thing.

    The Ubuntu version will sometimes print "ads" to your terminal :P.

    For a prod server, I'd choose Debian over Ubuntu if I didn't have paid support, because I'm not a fan of Canonical. If I needed paid support, I'd choose Ubuntu, because Debian is strictly a community distro. (That community happens to include major companies, like Google.)

  • Sure, but the interface is probably just as important as the actual logic behind it, isn't it?

    The logic is why I love Apt. Most robust dependency resolution algorithms I've used.

    But also, I don't have any issues with the CLI. Having a distinction between apt-get and apt-cache and apt-mark doesn't feel weird to me. You're practically just separating the top-level sub commands by a dash instead of a space. The apt command is really just a convenience thing, and there are specialized tools for the more advanced things. Which is fine by me.

    Also, the top level apt command doesn't guarantee a stable CLI, so for scripting you're supposed to use apt-get and friends anyway.

    Honestly I would consider that one of the fundamental things a package manager must do.

    You'd be surprised. Homebrew (the de facto standard package manager for macOS) doesn't do this. Though, you can at least lookup the "leaf" packages which are not dependencies of any other package.

    And, most language-specific package managers can't do this. E.g. if you install software with pip or cargo.

    you have to remember the extra step after it's finished installing

    If the package is in use, it shouldn't be an orphan.

    For example, what if you race with a cleanup job that is removing orphans? (Debian is hyper stable, so I often enable unattended upgrades with autoremove. I'm not so comfortable doing that on Arch ;)

    What you've described is just an apt-get install when you start and and apt-get remove when you're done. Or more properly setting it as a build dependency in your source package, to let Apt handle it.

    But also, why uninstall build tools?

    This, at least version constraints, is another one I'd consider essential tbh. The rest are great though, I agree.

    Yeah, version constraints are common. But most other package managers bail with an error when they encounter a conflict. Apt is really good about solving conflicts and proposing solutions. Often it will propose multiple solutions to your conflict for you to choose from.

    Again, it's the solver part of Apt that makes it the best IMO.