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.
I'll try recording something next time I clean one of the units (one needs a deep clean this spring); no promises though. In the meantime, here are some quick notes/resources.
- I cover the electronics in a garage bag held with tape. No need to unscrew the black cover over the power wires to disassemble (I unnecessarily removed this a few times heh).
- I ended up really liking this cleaning shrowd after trying a few; the hard pieces on the sides are key for making it easy to secure nicely, which many others lack: https://www.amazon.com/gp/aw/d/B083S85X97
- I spend more time (like 30min+) spraying the blower wheel so it spins. I alternate spraying with fresh water with spraying diluted "Lemocide" (@10% dilution) from a spray bottle a bunch of times depending how dirty it is. I use this <https://snowjoe.com/products/sun-joe-wa24c-lte-24v-150-psi-m...> which at 100 PSI is 10x stronger than a hand pump sprayer, but 10x weaker than a real pressure washer. I.e. the sweet spot IMO.
- I use foaming coil clean from a can to clean the fins if they're particularly dirty. (WARNING: I have not used in the same cleaning as the Lemocide since I haven't confirmed if they're compatible, so be careful of any reactions if you use both in the same cleaning.)
- I take the outer casings outside for a quick rinse with the hose and dish soap if they're really dusty.
- I tape cheap plastic mirrors at 45 degree angle above the unit so I can see it from above and carefully vacuum the back coil (there are 3 folded over in a U, and you can only see 2 from the front). Otherwise this just accumulates junk and is hard to see. This also really helps with finding the 3x clips at the top of the case that secure it to the back housing.
I may have a few more notes worth sharing at some point; feel free to ping me if you have any specific questions.
Edit: See also this quick video on unclogging the drain line on a Daikin (though I used the sprayer against the tube instead of my mouth...): https://m.youtube.com/watch?v=GDrHe-rli98
I love our Daikin mini-splits (came with the house), but as you allude to I've had to become an mini expert on deep cleaning them. They've can get GROSS with mold when used for cooling, and the cursory filter only does so much. That being said, now they stay clean for a few years after a deep cleaning -- though my first few attempt before I refined the process did not stay clean nearly as long. (Proper water pressure and disinfect is key.)
Cleaning basically involves a dedicated cover + drain that diverts water to a bucket, and blasting it with what's effectively a "low power pressure washer" I can use indoors (carefully), and "Lemocide" to properly disinfect... And coil cleaner for the fins. Takes me a good 4+ hours per unit, largely spent preparing the area in case there is any rogue spray. (Though TBH I may be a bit obsessive about getting it right.)
I also had a drain leak as you mentioned -- blasting the drain line with aforementioned "low pressure washer" helped with that. Still a bit gross to deal with. (And learning how to properly disassemble and clean the drip tray is the final thing I've put off leaning for a completely-thorough deep clean... I'm a bit horrified anticipating what I'll find...)
I think another part of this is that there is generally a significant moisture content difference between hot and cool air, leading to some additional gains versus thinking in terms of air temperature alone.
We had one of these installed in the last couple of years and love it. We wanted to keep our CO2 lower, without leaving windows open and introducing dust/whatnot. Works well quantitatively and qualitatively.
FYI the "industry term" for these is an ERV or Energy Recovery Ventilator. (I think I've seen them referred to as Enthalpy Recovery Ventilator -- but I assume that fell out of favor since it's too pedantic for most people heh.)
If you get one, one tip is to ensure the air inlet is covered with a fine mesh screen. This cut the number in bugs in the filter 95%+. Also you can upgrade the filter from what's included to MERV13 or whatnot for better incoming air filtration.
I do see where the general objection to the "current kills" comes from, even if their reasoning got a bit muddled.
All else equal, twice the voltage yields twice the current (and 4x the power).
So while yes, it's the current that kills you, in the majority of circumstances high voltage = high current. Outside of explicitly current-limited setups (e.g. a Van de Graaff generator or a desktop ionizer), most higher voltage devices will kill you more easily.
And so the "voltage doesn't kill" meme more often than not (IMO) gives laymen an undue sense of safety when working with higher voltages, at the benefit of appealing to the more electrically-inclined crowds sense of "being precisely correct".
Just look at the dozens deaths a year from people messing with microwave transformers, trying to make some pretty wood lightning art, for an example of this.
"You" are not "your thoughts": you are the watcher of your thoughts.