Ah - you have discovered my complaint.
That is precisely why I went with microk8s instead. I don’t install software from people who can’t be bothered to package their software using standard deployment tools which has been the correct way to distribute Linux software for decades.
You’ve made this about snap. Flatpak, rpm, deb, etc. all work too.
You’re welcome to make whatever bad decisions you like. I can manage snaps with standard tooling. I can install, update, remove them with simple ansible scripts in a standard way.
Bash installers are bad. End of.
Microk8s manages to install with a snap. I know that snap is “of the devil” around these parts but it’s still better than a custom bash script.
Custom bash scripts will always be worse than any alternative.
I really want to push back on the entire idea that it’s okay to distribute software via a curl | sh command. It’s a bad practice. I shouldn’t be reading 100’s of lines of shell script to see what sort of malarkey your installer is going to do to my system. This application creates an uninstall script. Neat. Many don’t.
Of the myriad ways to distribute Linux software (deb, rpm, snap, flatpak, AppImage) an unstructured shell script is by far the worst.
curl -sfL https://get.k3s.io/ | sh -
Never, ever install anything this way. The trend of “just run this shell script off the internet” is a menace. You don’t know what that script does, what repositories it may add, what it may install, whether somebody is typo-squatting the URL and you’re running something else, etc.
It’s just a bad idea. If you disagree then I have one question - how would you uninstall k3s after you ran that blackbox?
Yeah - I did come down a bit harder on helm charts than perhaps I intended - but starting out with them was a confusing mess for me. Especially since they all create a new ‘custom-to-this-thing’ config file for you to work with rather than ‘standard yml you can google’. The layer of indirection was very confusing when I was learning. Once I abandoned them and realized how simple a basic deployment in k8s really is then I was able to actually make progress.
I’ve deployed half a dozen or so services now and I still don’t think I’d bother with helm for any of it.
Yeah - k8s has a bit of a steep learning curve. I recentlyish make the conversion from “a bunch of docker-compose files” to microk8s myself. So here are some thoughts for you (in no particular order).
I would avoid helm like the plague. Everybody is going to recommend it to you but it just puts a wrapper on a wrapper and is MUCH more complicated than what you’re going to need because you’re not spinning up hundreds of similar-but-different services. Making things into templates adds a ton of complexity and overhead. It’s something for a vendor to do, not a home-gamer. And you’re going to need to understand the basics before you can create helm charts anyway.
The actual yml files you need are actually relatively simple compared to a helm chart that needs to be parameterized and support a bazillion features.
So yes - you’re going to create a handful of yml files and kubectl apply -f them. But - you can do that with Ansible if you want, or you can combine them into a single yml (separate sections with ----).
What I do is - for each service I create a directory. In it I have name_deployment.yml, name_service.yml, name_ingress.ymlandname_pvc.yml`. I just apply them when I change them, which isn’t frequent. Each application I deploy generally has its own namespace for all its resources. I’ll combine deployments into a NS if they’re closely related (e.g. prometheus and grafana are in the same NS).
Do yourself a favor and install kubens which lets you easily see and change your namespace globally. Gawd I hate having to type out my namespace for everything. 99% of the time when you can’t find a thing with kubectl get you’re not looking in the right namespace.
You’re going to need to sort out your storage situation. I use NFS for long-term storage for my pods and have microk8s configured to automatically create space on my NFS server when pods request a PV (persistent volume). You can also use local directories but that won’t cluster.
There are two basic types of “ingress” load balancing. “ClusterIp” means the cluster controller will act like a hostname-based router for HTTP. You can point your DNS entries at that server and it will route to your pods on their internal IP address based on the DNS name of the request. It’s easy to use and works very well - but it only works for HTTP traffic. The other is to use LoadBalancerIp that will give your pods an IP address on the network that you can connect to directly. The former only works for HTTP, the latter will let you use any ports (e.g. ssh for a forgejo instance).
“Good luck with that.”
I realize you’re inexperienced and excited, but this is truly no big deal. Port scans are quite common and aren’t even always malicious. You can use nmap to scan systems yourself - just to see what’s out there or to test if your firewalls are woking, etc.
You contacted Amazon over a port scan?
People have a psychological bias to humanize anything that communicates with them and companies are trying to latch onto that mechanism because they benefit when people get an emotional attachment to websites. So I think Google and many others are trying to make people think of websites as things with agencies, rather than machines controlled by people. And yea I think they are partly successful.
This is just stupid. I’m not going to sugar coat it. Nobody thinks their computer is a sentient creature save for some tiny percentage of people who may be mentally ill or otherwise disabled.
People can’t even tell the difference between their operating system and their apps.
There is an ENORMOUS difference between not understanding different layers of the technology stack and thinking your computer is a thinking creature.
Like I said originally - do you think people believe their television wants to sell them “Tide”? Or do they realize that it’s the advertising company. As you say - people love to “humanize anything that communicates with them” and they “do not understand technology”.
I get the “nobody ever went broke underestimating the intelligence of the general public” vibe - but do you really think that people believe that websites act with agency to sell them things?
I understand that it’s not the “YouTube program” having its own agency and making this decision - it’s the team behind it, driven by engagement metrics and growth targets. But does the average user understand this distinction?
Yes.
What a stupid question. Does the author think that people believe televisions want to sell them things too?
Many (most?) databases these days support some sort of full text search.
If a function has 300 lines without a lot of supporting documentation then I doubt that it is “clear, readable and concise” anyway.
Code - not function. Files often have multiple functions in them. If you can’t read and understand code - I don’t want you on my team.
I have never found it hard at all to skip past comments that are not relevant because my code editor helpfully colors them differently from the rest of the code, making it easy. Does your editor not do the same?
If it’s something people will simply skip over then it’s not useful. Don’t pollute code with tons of unnecessary comments that you think will be useful for some “perceived future”. They just add to your maintenance work.
Write your code to be understandable and document the architecture/design separately.
It depends on what you are doing. If you are implementing relatively simple logic like a REST API handler, then it is probably overkill. If you are implementing a relatively advanced algorithm, then having a running narrative of what is going can be extremely helpful.
Agree - most code is pretty straight forward. Save the comments for where it’s needed.
You want to turn my 300 lines of clear, readable and concise logic into 1,000 lines of English paragraphs that break up the functions of my code into yet smaller pieces of code devoid of context? Now I have to dig through that book, ignoring all the shit I’ve read hundreds of times because it doesn’t compile into anything, just to debug an off-by-1 error in a loop buried in a paragraph explaining the original developers diatribe on why we’re looping over that range? Fuck. No.
This is the sort of academic crap that sounds good but in practice is just terrible for anything other than small projects that are intended specifically to teach.
This is something I’ve said for a very long time. Everytime some RAD or “low code” tool claims that it will make developers obsolete because “you won’t need to write code”! I know that I’m going to need to help some BA use that tool and that there will be a tiny little box hidden in that tool somewhere which let’s me write code to work around its limitations.
LLMs are useful to a developer as a cordless drill is to an engineer.
Software development is about understanding logic, data structures, and how to solve business problems with computers. A language is simply what we use to do that.
That sounds so painful. Not surprising it never caught on.
I don’t make the rules. If you’re on lemmy qnd nextcloud does exactly what you want you need to complain about it being “over engineered” or “bloated” because it does things you don’t need.
Dude - you gotta get off the snap hate train for a bit.
Do you not understand the difference between “hey, run this rando shell script on the internet” and “hey, use this standardized installer which may run some shell scripts”?
I don’t give a shit about all the canonical hate. For me snap does what I want:
flatpak run something.something.somethingBS)It’s not bash I’m criticizing. Do you understand that? Because stop reading if you don’t and go back through my list. I’ll wait.
So good - you get that bash isn’t the problem. It’s the bespoke unstructured installer/upgrader/unisntaller part that is bad. You could write your installer in C, Python, etc. and I’ll levy the same complaints. You want me to install your python app? It should be available through pypi and pip. Not some rando bespoke installer.