• 1 Post
  • 344 Comments
Joined 2 years ago
cake
Cake day: June 30th, 2023

help-circle

  • Raspberry pis are an easy intro to actually using computers (instead of using something like windows).
    Raspbian is great (based on Debian) and there is a HUGE community for it.

    So yeh, it’s a great started for $25, as long as you have a PSU and SD Card. And an hdmi cable + monitor + keyboard at your disposal (and a mouse if you are installing a desktop environment (IE something like windows, whereas headless is a full screen CLI).
    And don’t get your hopes up for a windows replacement.

    But… Why not run a Virtual Machine? If you have a windows machine, run VirtualBox, create a VM and install Debian on it?
    That’s free. You can tinker and play.
    And the only thing you are missing from an actual raspberry pi is that it isn’t a standalone device (IE your desktop has to be on for it to be running), and it doesn’t have GPIO (ie hardware pins. And if this is your goal, there are other ways).

    If you really really want a computer that is on all the time running Linux (Debian, a derivative (like raspbian) or some other distro) - aka a server - then there are plenty of other options where the only drawback is lack of GPIO (which, in my experience, is rarely a drawback).
    And that is literally any computer you can get your hands on. Because the raspberry pi trades A LOT for its form factor, the ethernet speed is limited, the bus speed is limited (impacting USB and ethernet (and ram?)), the SD card is slower and will fail faster than any HDD/SSD. The benefit is the GPIO, the very low power draw, and the form factor - rarely actually a benefit.

    I’d say, play around with some virtual box VMs. See what you want, other than Fear Of Missing Out (things like PiHole? They run on Debian, or even in a docker container). Then see if you actually want a home server, and what you want to run on it.
    It’s likely you won’t want a raspberry pi, but a $150 mini pc that can actually do what you want.



  • Heck yeh! Great work.
    I think most critique has been covered.

    I consider too-many-indentations to be a code smell.
    Not actually an issue, but maybe there is…

    There is nothing wrong with your code, and no reason to change it (beyond error catching as you have discovered). It runs, is easy to follow, and doesn’t over-complicate.

    I like descriptive function names and early returns (ie, throw or return on all the conditions that means this function shouldn’t continue, then process the parameters to return a result).
    This could massively clean up what’s going on.
    There could be a “getUserCommand()” that returns the desired number, or 0 if it’s invalid.
    If the returned value is 0, then break.
    If the returned value is 6, then print values; then break.
    Otherwise we know the value should be 1-5.

    You could use an Enum to define the choices.
    This way, the print lines and the conditional tests can both reference the enum. It also removes “magic numbers” (IE values that appear in code with no explanation).
    In something simple like this, it doesn’t really matter. But it improves IDE awareness (helping language servers suggest code/errors/fixes). And Makes the code SOO much more descriptive (Ie “choice == 3” becomes “choice == Choices.Product”).









  • https://store.steampowered.com/steamos

    Does this mean I can install SteamOS on any device? We expect most SteamOS users to get SteamOS preinstalled on a Steam Deck or device that incorporates SteamOS. The only devices officially supported on SteamOS right now are Steam Deck and Legion Go S. We are working on broadening support, and with the recent updates to Steam and SteamOS, compatibility with other AMD powered PC handhelds has been improved.

    If you are interested in installing SteamOS on your device and providing feedback, you can follow the instructions here.

    here links to https://help.steampowered.com/en/faqs/view/65B4-2AA3-5F37-4227

    With instructions to install steamos and the note:

    Currently, the only devices officially ‘Powered by SteamOS’ are Steam Deck and Legion Go S. We are working on broadening support, and with the recent updates to Steam and SteamOS 3.7, compatibility with other AMD powered PC handhelds has been improved.

    So, it’s unlikely to be smooth sailing. But it can be done, and steam is working on improving it.

    There seems to be some forks out there that claim to improve desktop installation, but I have no idea how active or decent they are.


    Personally, I think steam is missing a huge market slice by not creating a steamos for desktops.
    However, they don’t need it and probably don’t want it. It’s a market slice in a market they don’t need or want: operating systems.
    People that would use it likely already have steam on windows. So, it’s not bringing in new customers (like the steam deck does).
    People that game on Linux likely already use Steam Proton (which is an amazing contribution). So, no new customers by distributing a whole desktop OS.
    It’s starting a fight with Microsoft (which I think we all want), but with no real benefit to Steam.

    I think steam is smart to stay in their lane of handheld OS and Linux tooling for gaming.
    Let the desktop gaming distros be maintained by other people. Ideally steam would support those distros, but just maintaining Proton and generally pushing Linux gaming is still a huge contribution.






  • especially once a service does fail or needs any amount of customization.

    A failed service gets killed and restarted. It should then work correctly.
    If it fails to recover after being killed, then it’s not a service that’s fully ready for containerisation.
    So, either build your recovery process to account for this… or fix it so it can recover.
    It’s often why databases are run separately from the service. Databases can recover from this, and the services are stateless - doesn’t matter how many you run or restart.

    As for customisation, if it isn’t exposed via env vars then it can’t be altered.
    If you need something beyond the env vars, then you use that container as a starting point and make your customisation a part of your container build processes via a dockerfile (or equivalent)

    It’s a bit like saying “chisels are great. But as soon as you need to cut a fillet steak, you need to sharpen a side of the chisel instead of the tip of the chisel”.
    It’s using a chisel incorrectly.


  • I would always run proxmox to set up docker VMs.

    I found Talos Linux, which is a dedicated distro for kubernetes. Which aligned with my desire to learn k8s.
    It was great. I ran it as bare-metal on a 3 node cluster. I learned a lot, I got my project complete, everything went fine.
    I will use Talos Linux again.
    However next time, I’m running proxmox with 2 VMs per node - 3 talos control VMs and 3 talos worker VMs.
    I imagine running 6 servers with Talos is the way to go. Running them hyperconverged was a massive pain. Separating control plane and data/worker plane (or whatever it is) makes sense - it’s the way k8s is designed.
    It wasn’t the hardware that had issues, but various workloads. And being able to restart or wipe a control node or a worker node would’ve made things so much easier.

    Also, why wouldn’t I run proxmox?
    Overhead is minimal, get nice overview, get a nice UI, and I get snapshots and backups