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.
"You" are not "your thoughts": you are the watcher of your thoughts.