I had just setup "Stirling PDF" on my home NAS a few of weeks ago, since my SO needed to merge some documents and I'd recently read that (or a similar) HN thread.
I definitely would recommend it. It was really quick to setup; though my already having a reverse proxy with wild card TLS certs setup probably helped streamline the networking side of things.
Just a warning to anyone reading this that 35% lab grade hydrogen peroxide can be VERY dangerous, so I'd just stick to the 2% drug store stuff unless you really know what you're doing.
High purity hydrogen peroxide has been used as a rocket fuel since it's such a great oxidizer.
+1 ours got so moldy inside. Especially after the hardwood installers ran them while sanding. I've gotten quite good at deep cleaning and sterilizing them, but it's a long and messy process.
I was in a similar boat and finally got around to trying out Proxmox in the last year or so. I just wanted share my own experience here, since it's a bit different than the "standard" uses I've seen.
I had been running a k3s cluster (k8s flavor) on some Raspberry Pis, but decided I needed some non-ARM nodes, and "invested" in a few low power "1L" AMD64 PCs (6-8 core + hyper-threading). I was initially going to just install Ubuntu and base my setup off my existing Ansible automation to make things less inefficient. But I figured I'd play around with Proxmox first and see if there was any benefit to using that as a base layer since I'd heard a lot about it.
I'm so glad I did. I ended up learning quite a bit in the process. Some quick highlights about using Proxmox for VMs in general:
* Proxmox supports creating a "cluster", so you can login though one machine to administer them all. You can conveniently "move" VMs between machines pretty seamlessly.
* If you install the para-virtualization drivers for e.g. Windows or Ubuntu VMs, you can do pretty fast remote KVM. E.g. I could run Youtube on a Windows VM in my basement over "Spice" and it almost looks like it's running locally. (Not that it's a use case I care about, mostly just shows the fact it's performant.)
In terms of actually getting around to deploying k3s on top of the infra:
* I ended up learning HPC-Packer, and HPC-Terraform, which integrated nicely with my existing Ansible experience.
* Packer turns an Ubuntu ISO + my "base" Ansible setup playbooks into a pre-baked machine template directly in Proxmox. (My local machine's Packer binary just orchestrates the process.)
* Terraform deploys the machine template into the Proxmox cluster. Basically a config file of machine names + IPs + mac adresses, and a few other params and initial setup.
* Ansible then installs any final dependencies (anything not in the base template), setups up the first k3s master, grabs the join token, and adds in 2 more master nodes for a proper `etcd` backend.
* Ansible then installs my base Kubernetes services (cert-manager, Rancher, Longhron storage, etc) via running helm commands on one of the nodes.
* This is where I'm at now; the next step is for me to deploy my existing Flux.cd-automated "Gitops" apps (built for ARM64+AMD64 via Gitlab runner, also in Proxmox). These _had_ been running on my now-quite-crusty-seeming Pi cluster.
I can run a single command to delete all the VMs, and rebuild + setup everything (full HA cluster + apps deployed and running) from scratch in ~6 minutes without any manual input required from me, just a few secrets/params in a config file.
This has made exploring the horizon of possibilities _so much easier_ without getting locked in; I can try to weird Longhorn storage configs, or try out k8s monitoring stacks without worrying about needing to "back out" my changes if I picked bad settings. (Just blow it up and try again!) I can change how VLANs are configured in early steps, or try adding a library to the base Ubuntu install cluster-wide super easily, etc.
I am primarily a software-engineer, so it has been really nice to delve into the operational side of things, and get a proper reproducible setup. It really has transformed how I think about the cluster in that it's no longer a "thing to carefully maintain", but instead a great sandbox to explore AND deploy my own k8s applications on top of without playing cloud bills.
My Proxmox journey in the past few months definitely turned into more than a rabbit hole than I'd expected.
Salts are generally stored with the hash, and are only really intended to prevent "rainbow table" attacks. (I.e. use of precomputed hash tables.) Though a predictable and matching salt per entry does mean you can attack all the hashes for a timestamp per hash attempt.
That being said, the previous responder's point still stands that you can brute force the salted IPs at about a second per IP with the colocated salt. Using multiple hash iterations (e.g. 1000x; i.e. "stretching") is how you'd meaningfully increase computational complexity, but still not in a way that makes use of the general "can't be practically reversed" hash guarantees.
It's common to conflate the effects of a solar storm with an EMP; when in reality they're opposite extremes of the same mechanism (i.e. voltage varying over distance).
An EMP is a short-duration high voltage spike; i.e. short-wavelength/high-frequency.
A solar storm acts on a large scale and causes a long-duration high voltage spike; i.e. long wavelength/low-frequency.
So an EMP (i.e. a high altitude nuke) will tend to induce high voltage in small "antennas"; i.e. circuits in an SSD or other transistor electronics like your concern.
Whereas a solar storm will induce high voltage in large antennas; think power lines or long cables. However these days there's enough warning and contingencies to mitigate the worst of these effects; i.e. preemptively shut down vulnerable power systems. The grid "crashing" and needing to do a cold start is still very bad, but far better than also getting damaged.
----
Edit: I also want to point out that the above is specific to "on the ground" effects as we're shielded by earth's magnetic field. Satellites still get bombarded directly with heavy radiation/particles, which is much closer to an EMP in terms of acute impact.
This has bugged me for so long and I hope the industry finally stops someday.
To summarize for anyone not versed in electrical power:
* mAh measures how much current your battery holds, irrespective of voltage.
* However, actual POWER is measured in Watts (or watt-hours cumulatively).
* Watts = current * voltage.
* A 2000mAh hour battery at 2 volts has half the power of a 2000mAh battery at 4 volts.
* As voltages can vary based on battery arrangement (parallel vs series cells), this makes a huge difference. You can half or double your mAh by arranging your cells differently, without changing actual power stored.
Using Wh or mWh instead of mAh would make this whole problem go away. But then that means low voltage batteries (like often used in phones) can't inflate their reported mAh compared to high voltage cells (e.g. in power tools). They also tend to conveniently leave out the battery voltage, so you can't tell when it's an apples to apples capacity comparison.
After having 2 bikes stolen back in college, my last (brand new) one was haphazardly spray painted rusty-brown and had cotton stuffing taped to the underside of the seat.
That one never got stolen, despite having it for much longer.
Assuming I understand you question: you can define an interface to describe what an object parsed from JSON contains, and then cast your raw JSON-parsed object into that type.
The casting doesn't guarantee the JSON from your server fits the interface, but it WILL ensure any downstream use is correct, and also enable auto complete for its fields (assuming your IDE supports it).
I've been using JavaScript on and off for nearly 20 years, and TypeScript is a massive improvement.
This is what helped me wrap ahead around the fact that gravity "is not really a force": when you are in free fall you feel 0 acceleration. You appear to be accelerating relative to the ground-- but you're actually motionless in an "inertial reference frame". (Similar to how the astronauts on the ISS don't "feel" acceleration despite accelerating rapidly relative to the earth.)
The "force" of gravity is often modeled as "gravity pulling you down" and the ground "pushing you back up". This works mathematically, but isn't quite logically consistent.
In reality, on the ground you're in a region of warped spacetime, so you feel constant upward acceleration despite not actually accelerating. (Thinking of this another way, standing on earth feels identical to being in a far away spaceship accelerating at 9.8 m/s².)
This is also why time "speeds up" near more massive objects. (Separate from "acceleration".)
We're so used to gravity this it doesn't seem weird. But when you consider the fact that free-fall is when you truly do not experience acceleration... well pondering that from many angles is what ultimately led Einstein to his model of relativity.
(This is me trying to condense what could be a 10 minute explanation into a few sentences, so apologies if it's not particularly clear.)
I completely agree that for managing the host nodes/machines, Ansible is a huge win. Though this article focuses on deploying ON the cluster.
Ideally the complexity of deploying ON a cluster (i.e. 'kubectl apply') doesn't increase with its size. In some ways it actually gets simpler, as you can worry less about per-node scheduling due to resource constraints/packing.
This went a different direction than I'd expected. That is, configuring your cluster resources rather than the host machines themselves.
I managed to grab 5 or so Raspberry Pi 4s before the availability issues. I've been (slowly) getting a home Kubernetes cluster running over the last year or two, and Ansible helps immensely; I:
* Write Ubuntu 20.04 (or now 22.04) to MicroSD card.
* Configure the initial user + SSH-PK, hostname, and network via config added to the SD
* Boot up the new Pi
* Run Ansible playbook to get it ready for k3s (lightweight but "full" k8s); including bind-mounting all high use paths for containerd/logs/etc to a USB NVME-SSD, adding boot args to the Pi's GRUB, etc.
* Push all my bashrc/tmux/vim/etc configs for consistent environment if I ssh in.
* Use Ansible ad-hoc for misc changes or package updates.
In terms of the "deploying to Kubernetes", I've recently got FluxCD working and love it. I think "GitOps" is the way to go in terms of clear reproducible config.
I have GitLab running on a local Synology (NAS) which kicks off any container builds and hosts the Git and container registry. The FluxCD operator on the cluster polls my "cluster as code" repo and syncs state. Each project defines a Helm chart and Flux pulls the chart from each repo and applies any variables (as configured in the "cluster repo") or "kustomizations".
Flux let's you setup "dependency" relationships for components. So I have it add the sealed-secrets operator early in, and put PK-encrypted secrets in directly the Git repo for it to"unpack" in the cluster.
That being said, the author's Anisble-driven approach is a much quicker way get something on a cluster ASAP, versus setting up the initial Flux "pull from cluster" system.
I'm primarily a software engineer, so this was also largely an exercise in getting more comfortable with the operations side of things.
Just thought I'd share my experience since only so many people let me rant about my FluxCD/k3s/GitLab home dev environment.
I believe they fall under the "amateur" bands. I.e. frequencies not requiring a license to utilize (given you obey given power limits). That's why the same frequencies are shared by WiFi, Bluetooth, ZigBee, etc.
Some of the amateur bands also overlap with allocations for things like radar. For example, a subset of the "5Ghz" WiFi channels (the "DFS" channels) can only be used if the access point will auto switch to a different channel upon detecting a radar pulse.
"You" are not "your thoughts": you are the watcher of your thoughts.