i’m lizard 🦎

  • 1 Post
  • 33 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle



  • It’s not what the buttons look like, it’s what they do. In Krita, making an ellipse involves clicking the ellipse button and dragging it somewhere. You now have an ellipse, and you hold shift if you want to make it a circle instead.

    In GIMP there is no direct ellipse tool, there’s only an ellipse select tool, likewise you hold shift to make it a circle. Then you use a menu item to select the border of your selection, getting a popup to let you determine how much pixels you want. And then, you use the fill tool or fill menu item to fill it. That’s a surprising amount of clicks to accomplish what’s most likely the single most common task for anyone opening a screenshot in an image editor. I’m not aware of any easier/faster method to do it. Feels like it should exist, but this is also what you get if you search for how to draw a circle in GIMP, so if it exists everyone’s missing it.

    GIMP’s method gives you more power, but you rarely ever need that power. But when you do, Krita also has ellipse select, border select and various fill tools that can be strung together in the same way.







  • Note: The HTTP/3 QUIC module is not enabled by default and is considered experimental

    Do note that despite not being enabled by default, it is enabled in the official binary packages.

    There’s a funny amount of layers to this thing but as far as I’m concerned, if it’s a feature you ship in the default binary packages on your site, that is definitively enough for a CVE even if it’s disabled by default.




  • You can hardcode a specific version of nixpkgs, instead of a branch. With the new Nix CLI & flakes enabled you can do something like this:

    nix run "github:NixOS/nixpkgs/b4372c4924d9182034066c823df76d6eaf1f4ec4#cowsay" "moo mooooooo"
    
    

    That’s the commit I’m seeing for nixos-23.11 today, and it should still give you that exact version of cowsay years from now.

    Of course, the better option is to make a dev shell with flakes. Flakes come with a lockfile builtin that accomplishes the same effect, and there’s no problems having different projects on different lockfiles/versions. It’s a bit more work to learn, the Zero to Nix tutorials are pretty decent at teaching and come with examples though (ultimately most things are ~30 lines of boilerplate and a list of packages that you want).







  • chameleon@kbin.socialtoOpen Source@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    23
    arrow-down
    2
    ·
    1 year ago

    OpenSSH’s server login component (the authorized_keys checking) can’t properly respect XDG_CONFIG_HOME because it won’t be set at the time it’s reading the authorized_keys file. The user’s home directory is stored in /etc/passwd but the XDG variables have a million different ways to set them, none of which are truly standardized. Best you could really do is hardcoding .config or the like, which you can do by changing the AuthorizedKeysFile in sshd_config.



  • Even if the source is kept decently preserved, the build environments are usually not. If they still have a machine in the exact state it was in at the time the game was finished, it might be as easy as Project -> Build, but… they almost certainly don’t. So that likely has to be rebuilt from scratch, and you’d be very lucky to find any kind of documentation on how things worked.

    Game studios tend to have it particularly bad because of how much binary-only engines/middleware (standalone bits like Havok physics/Bink video/etc) they used, how often the game’s data and code builds were mixed together in some way and how in some cases the project is designed to build things like console releases at the same time. If you lost the install files for your physics engine, you’re probably straight up screwed.

    By the time you’ve figured all of that out, you can be easily hundreds of hours in, with tons of weird little issues that might require different people to solve. Some examples: you might end up needing to build it in Windows XP because no other OS runs all of the software used during the build, any sysadmin is NOT going to be happy installing WinXP on their network so the machine has to stay offline, getting code onto that machine might be a pain due to how Perforce or whatever is used by them, even things taken for granted like a particular version of the DirectX 9 SDK might be hard to find, etc. Sometimes licensing/activation of tools used in the build process is an impossible to solve problem because it needs some DRM dongle or activation server that no longer exists and the software was never publicly available, so there is no crack.