• 0 Posts
  • 18 Comments
Joined 6 months ago
cake
Cake day: April 20th, 2026

help-circle

  • Yeah? You should still make a decision. If you want it possible to watch, star and fork the repo from any of the sub-pages, then that stuff has to live in that top ribbon.

    But then you shouldn’t duplicate it into the Code sub-page. I’d work with split buttons, where you can look at who starred and you can add your own star, all from the same UI element. It would not even take up more space, since they do already display the count in the top ribbon as well.

    Apparently this is how Codeberg does it (see e.g. this repo), so this might be where I have the idea from…


  • I mean, yeah, it can make sense to duplicate information. That screenshot isn’t supposed to say that all of these should be deduplicated.
    But you really gotta be cautious with duplication, because it makes everything else harder to find. And I would absolutely argue that GitHub has crossed the line where they duplicate too much, across the board. It feels like design-by-committee.

    This is entirely anecdotal, but what really dumbfounded me while annotating that screenshot, is that I never actually read the links in that “About” section.
    I’ve seen this page probably a thousand times already, but I had no idea that there’s an “Activity” link there, which actually seems like it could be useful. Nor a link to the README, to the CONTRIBUTING.md or for “Custom Properties” (whatever that is).
    I had no idea how to report a repo until now, even though the link is apparently always on screen.

    There’s just so much info there, and it’s presented like read-only info, not like navigation links, so I always just skipped over the lines that don’t have numbers in them. I also genuinely never tried clicking any of these lines before…









  • In ‘proper’ software development projects, you (ideally) want all information checked into the repo for what is needed to run the software:

    • which dependencies you need,
    • what particular versions of the dependencies,
    • as well as which runtime/compiler version to use.

    And then you’d use a package manager which can automatically install all these.
    Python projects are currently heavily moving towards uv for this. Traditionally, you’d use pip + virtualenv + sometimes pipx for this.

    Using nix develop with flakes is also valid for this, if your team agrees on it: https://nixos.wiki/wiki/Development_environment_with_nix-shell#nix_develop

    Whichever way you solve it, the idea is that:

    1. You can check out a commit from months ago and just run it right away. Well, or just a commit from yesterday, which is on a different Git branch, where you haven’t yet started your big dependency upgrade. As soon as upgrading a dependency requires changes in your code, you want the dependency version change tracked together with the respective code change.
    2. Your different team mates can all work on the repository, even though one of them might be on Debian, the next on Arch and the third is on macOS. By defining all your dependencies in the repo, you can avoid “works on my machine” scenarios, where a bug occurs on one PC, but not on the dev’s PC where you try to reproduce it.

  • I mean, it could most definitely be better, but I really don’t think that it’s worse on Linux. Error handling is one of the hard problems in computer science in general.

    And well, at least you do get easy access to logs and error messages on Linux, which makes it infinitely better in many ways, but is also at least partially why this post exists.
    On Windows or such, you’d instead put a vague description into a search engine and hope someone had the same symptoms before…


  • Apparently, both ways of doing it exist:

    To make chunky peanut butter, peanut pieces approximately the size of one-eighth of a kernel are mixed with regular peanut butter, or incomplete grinding is used by removing a rib from the grinder.

    https://www.madehow.com/Volume-1/Peanut-Butter.html

    Personally, I figured, it could be bad when you don’t grind them fully, because you might end up with very large peanut chunks still left, but I guess, that’s kind of answered just before the previous quote:

    Peanut butter is usually made by two grinding operations. The first reduces the nuts to a medium grind and the second to a fine, smooth texture.

    So, I guess, you just do an incomplete grind for the second grind…



  • trem@lemmy.blahaj.zonetolinuxmemes@lemmy.world•dank
    link
    fedilink
    arrow-up
    4
    ·
    4 months ago

    Hmm, yeah, that is interesting. I’d say every native German knows “nix” (as in nothing). Maybe 10% would be aware what a “Nixe” is (female water spirit).

    Personally, I wasn’t even aware that there’s a male version. I could’ve guessed what it means, when used in a sentence, but if you asked me without context, I probably would’ve been too thick to figure it out. 🙃


  • I’ve always seen fans call it “cutting edge” or “leading edge”, as it’s somewhere between other distros with it shipping most feature updates once every six months.

    Personally, I prefer something more up-to-date, but at least you don’t typically get stuff in the Fedora repos that’s so out of date, that it’s actively broken.
    For example, for $DAYJOB, I need the reuse CLI, which states in its documentation to install it with apt install reuse. On Ubuntu 24.04 LTS, that’s just a dumb idea, because the version in the repos is 3 years old and crashes when you go to use it, producing subtly wrong results. That cost us half a day of debugging this week, for no good reason…



  • You’re doubly confused. You’re thinking of GitHub Copilot, when this is about M365 Copilot. Last I heard, they have 78 different products called Something Copilot, so confusion is understandable.

    But then what you’re actually thinking of is the “GPT” series of large language models, developed by OpenAI.
    GitHub Copilot is merely a GUI and a harness for large language models. It defaults to the GPT models, and is probably somewhat optimized for them, but it can use other models as well.

    This harness can influence the quality quite a bit, as it decides which source code files to feed into the model for context. I’m not aware of people saying that GitHub Copilot is particularly good at that, but it’s available as an extension for IDEs, so it automatically knows which files you’re editing, which can be useful.

    And yes, the GPT models have fallen quite a bit behind since the start of the year.