Olympic weight plates for barbells. They're widely used, so competition has brought the cost down, and they're easily available in useful increments. I currently see 4x 10lbs for <$50 on Amazon. That works out to 2,53 Euro per kg. So cheaper than euro cents. They may not have the exact shape you need.
The scrap steel probably didn't cost cents per kg when it was sold for its original purpose. You are paying for a useful shape.
A professional equivalent of weighted vests are ballistic plate carriers. Real ballistic plates can be fragile and expensive, so options for exercising in (or milsim games in airsoft etc.) include expired (and failed to re-certify) real ballistic plates, made for purpose training plates... or plate shaped sandbags!
For general public restrooms, you can also search OpenStreetMap for amenity=toilet and access=yes (which means explicitly open to the public; see also access=customers). Try it: https://overpass-turbo.eu/s/1ORn
The main technical limitation is that /24 is the smallest prefix that is widely accepted. So you can't just announce a /32 (single IPv4) at different locations.
Generally speaking, if you own the IP space, it just needs to be announced in BGP and traffic will come. You can either peer with someone yourself and get transit from them, or have them advertise it for you.
It's possible even for a private person to do it, if they have one of several workable mixes of knowledge, time, cash, contacts and technical requirements. I've done it for a while.
The main practical question really is who will peer with you and with what conditions. For example, your ISP will absolutely not do this on a consumer plan, but might on a business plan. AWS will do it for busineses as well: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoi...
If you want to learn more about BGP, anyone can sign up for DN42, which is a free, large, shared environment that is a small scale replica of the internet. Everyone gets to be their own AS, get some IP space allocated, establish links to other participants (usually VPN tunnels over the real internet), and do BGP peerings over them. https://dn42.eu/Home
It's written in an ambiguous way and you interpreted it incorrectly. "G5 Conditions were first observed at Earth at 6:54 p.m. EDT today." should be read like "today, G5 conditions where first observed at 6:54", not "G5 conditions where first observed today (at 6:54)".
Those are all arguments for buying Tesla stock, not a Tesla. Of course Tesla will keep selling new cars.
What if Tesla pulls the rug on existing models and stops supporting them after a few years? It's not an outlandish fear. Musk has been wildly unpredictable, anything could happen. And given e.g. the recent story about how a Tesla car wouldn't even start again without calling support for some kind of remote maintenance, Tesla owners seem to be more dependent on the company's support than average. It wouldn't surprise me at all if Teslas were generally one expired TLS certificate inside the car away from being bricked.
Unraid is not confidence inspiring either. It's just more commercial closed source software, developed behind closed doors and with a slow update cadence (~3 months). They have made questionable security choices anywhere you can see, and I have strong doubts that their code quality is any better.
The PHP scripts certainly are a horrible mess, in all ways. For example, shell injection prevention is based on using escapeshellarg at each call site... that pattern is _exactly_ the structural root cause for vulnerabilities like the one D-Link had.
In no particular order, and obviously not exhaustive: Everything runs directly as root - nginx, php-fpm, smb, ... No AppArmor/SELinux. There is no Secure Boot support (especially unfortunate since boot is from USB stick). No HTTPS access to web frontend by default. SMB protocol defaults are insecure. SMB shares default to public. SSH allows password-based root login. Pools are unencrypted at rest by default. They have a checkbox to enable telnet for management! Very permissive iptables rules. Almost any features that real competitors like Synology would officially provide come from third parties via a moderately shady app store.
Note it's not about any of these individual points. I see above as signal that they are not security experts and see security as an afterthought, rather than as something that deserves a team of experts that specifically cares about it.
(There's certainly other fields they also aren't experts in, like UX - their predominant UI pattern is "list of dropdown fields". Even in storage, one could have a longer discussion how their Array feature - the true core of their product -, compares to modern solutions. There's a reason they've evolved cache pools to just pools as a separate thing, and some users do pool-only Unraid...)
That's all quite understandable since it's a small team with only 2-3 coders (https://unraid.net/about). But nevertheless.
> Everything runs directly as root - nginx, php-fpm, smb,
For the record: you need root on Linux to open ports below 1000. By necessity, these programs need at least one thread that runs as root just from that.
Can't comment on the rest. As I never used it. Fedora server + cockpit UI was enough for me when I switched from my Synology NAS the other day
You can use cap_net_bind_service to bind ports <1024. You can listen on >1024 and redirect in iptables, or even with a trivial TCP proxy.
There are options on pretty much any system, but certainly on Linux with capabilities. None of these require direct support from the application (dropping root after binding does).
You almost never need to run anything as root, especially not with these "run 6 different types of services in a box" type of appliances.
None of this is new; this was already widely considered best practice when I was starting out 25 years ago.
in its service file. Note that this will necessarily allow the process to listen to any port; there is, unfortunately, currently no way to lock it down to a single port.
You can drop root after binding, or you can use capabilities to allow a particular program to bind on privileged ports. php-fpm could listen on a UNIX socket instead of a TCP socket.
Exactly. A more modern secure approach is to let the init system open the socket and pass it as an FD. This has some side benefits too (not even temporary root for daemon, less custom code, standard&declarative config, socket activation).
(Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)
I was specifically referring to hereditary peerage in the House of Lords, which was almost completely done away with. At around 13% of members, the chamber is largely no longer a chamber of hereditary peers. Hereditary peerage and hereditary peerage participation in the house of lords are separate. There are around 800 hereditary peers, but since 1999, only 92 of these hereditary titles have a spot in the house of lords. The hereditary peerage granted to Prince Edward is not one of the 92 hereditary peerages in the House of Lords, so it doesn't allow him participation.
The obvious difference is that the throttle axis on RC transmitters is not self-centering. 0% is at the bottom, not in the center.
But beyond that, the stick throws are much larger than e.g. on an Xbox controller, there's much finer feeling, the end stops are harder, the sticks can be held differently (search "thumbing vs pinching", both are used irl but the latter gives finer control). It's just so different. And you can't compare at all to using two full sized joysticks, which would mean full wrist movement.
Also, cheap gaming joysticks are terrible. Two high quality ones (VKB NXT or better) cost more than a high quality RC transmitter. It does not save money.
Physics aren't really realistic. They're all enough to get the absolute basics down (e.g. that camera uptilt means that pitch left/right needs a corresponding yaw input to keep the view straight). But then different simulators vary. The most common, fairly ubiquitous complaint, is that it's too floaty (real quads drop much faster without throttle). It's not just due to bad physics, it's also because to be commercially successful they have to appeal to gamers too, maybe even primarily. Then there's the finer points, like wind, descending into your own chaotic vortex, or how easy you crash when you touch anything (sims are sooo forgiving).
And of course every quad is different, 1" 1S, 3.5" 2S Li-Ion and a 10" 4S handle substantially differently, but if you haven't flown any for real then you won't know what is right.
(If you're looking for a radio, unless you know what you want, just buy a TX16S please.)
(There are exceptions to everything I said above. But this is the common case.)
I mean, I figured every different size drone would handle differently.
I guess I am surprised there isn't or can't be a quadcopter simulator with really realistic physics though in this day and age. Maybe just not enough market for it for that level of accuracy and realism.
To be clear, I don't want to imply they're useless though. Velocidrone, DRL and Liftoff (I haven't tried Uncrashed yet) all have good enough physics for real use cases, and are widely used.
- As a beginner, they help you crash less. You can learn enough basics to save some real money in avoided crashes. The sims pay for themselves right away, you can just buy them all. The sim-isms don't matter so much.
- As a skilled pilot, they help you crash more. You can safely iterate on your maneuvers really really well (no repairs, immediate retry from same conditions, always good weather, fly from home). You'll have an idea where the differences are and how you need to compensate with the actual craft. You can tune the virtual counterpart to be a bit closer.
They complement real model flying, they just cant replace it. (And even that is questionable. I bet many just can't afford real model flying. Sims might help them scratch the itch.)
A _really accurate_ flight sim is actually hard to do though, for a few reasons. Aerodynamic modelling is hard (there are lots of interesting effects), and that almost every model aircraft is unique (due to home building) and constantly changes (crashes, repairs, upgrades) probably doesn't help. And neither does that the core idea behind multirotors is unstable flight, which entirely depends on the firmware. There are different firmware projects (Betaflight is the most popular for racing, but not the only), and they are quite tunable. Can't simulate that accurately; it would have to be firmware in the loop.
I've recently been experimenting with nix generators. It's nice.
What's the most pleasant way to develop and build nix images if your dev env is a regular Linux distro without nix installed?
So far the least bad seems to be running Nixos in a VM with VS Code remote via SSH and scp'ing images around. At least quickemu makes getting the VM pleasant. But VMs are cumbersome.
Docker would be great, but nix from the official Docker container doesn't seem to like running as non-root, which means you can't use volume mounts for the code and change the user ID so that the file permissions are right from inside the container.
