Aussie living in the San Francisco Bay Area.
Coding since 1998.
.NET Foundation member. C# fan
https://d.sb/
Mastodon: @dan@d.sb

  • 0 Posts
  • 276 Comments
Joined 3 years ago
cake
Cake day: June 14th, 2023

help-circle

  • dan@upvote.autoSelfhosted@lemmy.world•Git control for novice gamedev?
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    1
    ·
    edit-2
    4 days ago

    I’d recommend learning Git entirely locally first. Git is a distributed version control system, which means that it doesn’t need a server. All of Git’s features are available to you even with just a local repo.

    Honestly, using Github is totally fine as a beginner. Similarly, using a GUI is totally fine. Dont let people shame you into using the CLI all the time if you don’t want to. It’s good to have a high level understanding so you can deal with things when the GUIs play up, but day-to-day usage is totally fine in a GUI. I like gitg because of how simple it is, but I like the Git integration in VS Code, and Jetbrains IDEs (Rider, WebStorm, etc) too. I’ve heard good things about GitKraken but it felt a bit slow last time I tried to use it.

    When you do want to have the repo on a self-hosted server for your own use, you don’t actually need anything fancy like Gitlab or Gitea. Technically all you need to do is copy the repo from your computer onto the server and set up a Git server on it. That’s it. Git works over SSH, so you’d just add a “remote” that points to the server.

    The best place to start with that is probably the official documentation: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols

    The repo on the server is not really any different to the one on your computer. All you’re doing when pushing is synchronizing them - pushing new changes from your local repo into the one on the server.

    Where web UIs have an advantage is that they make it easier to browse the repo, show it to others, have pull requests and CI support, etc. Lots of value-add features on top of Git itself.

    I’d highly recommend Forgejo instead of Gitea. The Forgejo site has a list of reasons why, so I don’t go over that in detail. Forgejo is what powers Codeberg, so you could try Codeberg first, then if you like it, self-host the exact same system. Note that Codeberg only allows open-source projects.


  • If you do buy refurbished drives, ideally get manufacturer refurbished ones that come with a manufacturer warranty. If you’re in the USA, ServerPartDeals is a great store for it.

    Manufacturer refurbished drives tend to be pretty reliable because they’ve been tested to meet the manufacturer’s specs, usually including a deep stress test, and come with a warranty from the manufacturer.

    The thing that sucks at the moment is that refurbished drives cost more than the new ones used to cost.






  • tl;dr it’s a relatively sophisticated approach to make it look real. The fake site reverse proxies the real online ordering site so that it looks and behaves exactly like the real one, blocks some scripts like trackers or anything that’d redirect back to the real site, and swaps out the payment form for a fake one.

    The payment details entered into the fake form go to a live operator that immediately tries to use the credit card elsewhere online. They get through 3-D Secure (where the bank requires verification of suspicious-looking online transactions) by asking the user to confirm the transaction, e.g. by providing an SMS confirmation code or confirming the transaction in their bank app.

    If you didn’t see the incorrect domain name, I think this would be very hard to notice, since the site functions normally. Very different to a regular phishing page where the site looks out of place and is often full of broken links (since they don’t want you navigating away from the fake login page)








  • Wireguard and apps based on it (like Tailscale) don’t respond at all unless the data is signed with the key of a configured peer (or with Tailscale, a system on your tailnet that passes the ACL). It’s literally impossible for an outsider/attacker to detect with a port scan since it just ignores unauthenticated packets.

    The Wireguard codebase is also extremely small. The core Wireguard implementation (the version in the Linux kernel) is around 5,000 lines long, so an experienced developer can read through all the code if they dedicate a day or two to it, and understand how it works.

    For comparison, OpenVPN is around 70,000 lines of code and OpenSSH is around 150,000 lines of code. There’s a huge number of features in SSH!





  • Different philosophies.

    On Linux, you can delete a running application and it’s fine, because files aren’t actually deleted until the last process that has it open closes it. This applies for all files, not just executables.

    Internally, files are mainly identified by an inode rather than the file path. If you delete a file then create a new one with the same name, the new file will have a different inode number to the old file. Anything that had the file open will still have a valid reference to the old file. If you’re running a program and upgrade it while it’s running, the currently running version will still be using the old inode, while any new instances will use the new one.

    Windows doesn’t do that. On Windows, the file path is the main identifier for the file. Files that are in use and executables that are running are locked and can’t be modified. It tells you to restart so that it can swap in the new files after closing everything. When updating a program, you just need to close it to be able to update, but OS files need reboots because they’re locked the whole time the OS is running.

    Note that some versions of Windows don’t require that any more. Some editions of Windows Server 2025 support hotpatching. This patches code (both OS code and program code) directly in memory, avoiding the need to restart to apply the update. On Linux, there’s a proprietary system called Kernelcare that does the same thing for kernel patches.