• 11 Posts
  • 275 Comments
Joined 6 years ago
cake
Cake day: May 31st, 2020

help-circle
  • If you’re an end user, not a build tool, you’d rather want to place that in .git/info/exclude inside the repo. It’s effectively another gitignore file, which won’t be committed.

    But if you do need something like this for a build tool, then yeah, you can create a file /test/.gitignore with these contents:

    real-person-first-last.json
    .gitignore
    

    Then running git add . just adds /test/fake-person-first-last.json.

    Both /test/.gitignore and /test/real-person-first-last.json would be ignored right away.


  • Well, if you’re the build tool that creates that build-folder, then it just means you don’t need to bother your user with adding it to the root gitignore.

    One time, I implemented it for basically a repo-specific download cache folder. Ideally, my users don’t need to know of that folder at all.

    Or recently, I implemented it for a build tool where my users might not be devs. They might not use Git at all, or not be very adept at it, so I’m glad to not need to document it…


  • Had a quick playaround with it:

    • Yes, that does prevent gitignore files from being committed.
    • It does not prevent locally-created gitignore files from being applied.

    But I’d say the latter is overall a good thing, as some build tools will do a echo "*" > build/.gitignore to have their build-folder add itself to the ignore-list.



  • Ephera@lemmy.mlto196@lemmy.blahaj.zone•Mosquito rule
    link
    fedilink
    English
    arrow-up
    17
    ·
    1 day ago

    A week ago, I took a walk through some nearby woods, came back home, took my jacket off, then found this kind of bug on the floor, with one of its hind legs missing:

    Stink bug with brown coloring

    So, I assume, it latched onto me during my walk.

    Anyway, I caught it and yeeted it off the balcony. Problem solved.

    Next morning, I walk out the front door of our house and see the same bug sitting on a wall there, with the same hind leg missing.
    The front door is on the other side of the building, so I thought, huh, funny coincidence that you traveled quite a few meters, but still stuck to the same building.

    Yesterday morning, I suddenly hear an insect in my appartment. It sounded like a fly beating its wings. I was really confused, because I have flyscreens on all windows. I only had the balcony door open for a minute in the previous evening.

    Anyway, you guessed it, it was the same bug again, same hind leg missing. Getting a bit creepy now. 😅

    I yeeted it off the balcony again, but if it shows up another time, I’ll have to carry it back to those woods and hope that it doesn’t find its way back…



  • Had to just think about why #[non_exhaustive] exists, so perhaps this helps you as well:

    Imagine you’re developing a really important core library, something like TCP. And then other libraries depend on your library.
    Now, if you change your implementation, you may need to introduce a new error case, even though the rest of the API still works the same.

    You have two choices to deal with that:

    • Release version 2.0, because that’s a breaking change. Each library that depends on you needs to manually upgrade to version 2.0. Some never will, because they’re unmaintained. Any application that ships your library as a transitive dependency will need to ship both, version 1.0 and version 2.0, for the next few years until the last of their direct dependencies has upgraded to 2.0 or been removed.
    • Or: You’ve declared that error enum #[non_exhaustive] before going 1.0 and therefore forced all depending libraries to implement a default match case. You can sneak in the new error case in version 1.1 without all those depending libraries needing to manually upgrade. The ecosystem does not split in half between 1.0 vs. 2.0.

    Obviously, if it’s a really egregious new error case that needs specific handling, then you might still want to release version 2.0, but by adding the #[non_exhaustive], you can decide later on and if you are such a central library, there’s definitely going to be situations where you want to make use of it.






  • Well, they would typically have a system prompt (like an invisible chat message that’s sent to the LLM at the start of the conversation), where it would tell the LLM something like “You’re a helpful chatbot. Talk cheerfully and use 🩵 all the time.”

    And in that system prompt, you can also give it instructions to only answer certain questions. But it really is like a chat message, in that it just as well might ignore those instructions when another chat message asks it to.

    OP chose the formulation “Before I subscribe to a creator, …” which might be necessary here to get it to answer, as it might have been told to only help with creator subscriptions, but then the formulation implies that by answering this question, it is helping the user to subscribe. That’s called a prompt injection.

    If you can find a prompt injection, then yes, you can do this with any chatbot.
    Although they might still not be as useful as a dedicated tool, since they likely can’t do tool calls, like web searches or running the compiler.


  • In hopes of this question not being a practical joke 😅:

    The desktop environment makes more of a difference than the distro. Switching distros will also give you a different desktop environment (because not much else uses the Cinnamon desktop environment that Mint uses), but yeah, you’ll probably care the most about the desktop environment.

    So, instead of choosing between distros, I would recommend choosing a desktop environment, for example look at KDE Plasma and GNOME Shell.

    And then you can either:

    1. install it on Linux Mint in addition to Cinnamon. You will be able to switch between them from the login screen.
    2. Or you can pick a distro that offers your chosen desktop environment out of the box and switch to that distro.

    I will say that option 2 is kind of ‘cleaner’. It will be better tested and integrated, if it’s officially supported by the given distro + you start from a clean slate where Cinnamon isn’t also installed.
    But yeah, I would actually recommend starting with option 1. You won’t have to learn both a new desktop environment and distro at the same time. And it’s less big of a step in that you can easily switch back, if desired.

    As per usual, do make a backup whichever option you go with. Sometimes, it can cause problems to have two desktop environments installed, because they might edit the same config files, so it’s good to be able to revert…



  • Yeah, not a bad stance to have. When I switched to Linux (in the middle of a compsci minor), I thought I was the king of the world and that I knew everything about computers.

    Then Linux showed me that I know fuckall, not because it was particularly hard, but rather because it’s an open library.
    You can look at a random config file on your PC and it will explain you highly technical concepts for free.
    You can look at the source code of anything you’re interested in. Well, or probably rather read an explainer from someone who read/wrote the source code.
    And you can easily look at the logs of your applications to debug them.

    Every so often, I run into folks that genuinely seem to know a lot about Windows, and I always wonder how. It doesn’t explain anything to you. 😅