While it sounds a bit hacky, I think this is an underrated solution. It’s actually quite a clever way to bypass the whole problem. Physics is your enemy here, not economics.

This is kind of like trying to find an electric motor with the highest efficiency and torque at 1 RPM. While it’s not theoretically impossible, it’s not just a matter of price or design, it’s a matter of asking the equipment to do something it’s simply not good at, while you want to do it really well. It can’t, certainly not affordably or without significant compromises in other areas. In the case of a motor, you’d be better off letting the motor spin at its much higher optimal RPM and gear it down, even though there will be a little loss in the geartrain it’s still a much better solution overall and that’s why essentially every low speed motor is designed this way.

In the case of an ammeter, it seems totally reasonable to bring it up to a more ideal operating range by adding a constant artificial load. In fact the high precision/low range multimeters and oscilloscopes are usually internally doing almost exactly the same thing with their probes, just in a somewhat more complex way behind the scenes.

The end result is exactly the same.

The difference is that you can install an iso on a computer without an internet connection. The normal iso contains copies of most or all relevant packages. Although maybe not all of the latest and most up to date ones, the bulk are enough to get you started. The net install, like the name suggests, requires an internet connection to download packages for anything except the most minimal, bare-bones configuration. The connection would hopefully be nearly as fast if not faster than the iso and be guaranteed to have the latest updates available which the iso may not. While such a fast connection is usually taken for granted nowadays, it is not always available in some situations and locations, it is not always convenient, and some hardware may have difficulty with the network stack that may be difficult to resolve before a full system is installed or may require specialized tools to configure or diagnose that are only available as packages.

In almost all cases, the netinst works great and is a more efficient and sensible way to install. However, if it doesn’t work well in your particular situation, the iso will be more reliable, with some downsides and redundancy that wastes disk space and time.

Things like windows updates and some large and complex software programs and systems often come with similar “web” and “offline” installers that make the same distinctions for the same reasons. The tradeoff is the same, as both options have valid use cases.

To be fair, in the case of something like a Linux ISO, you are only a tiny fraction of the target or you may not even need to be the target at all to become collateral damage. You only need to be worth $1 to the attacker if there’s 99,999 other people downloading it too, or if there’s one other guy who is worth $99,999 and you don’t need to be worth anything if the guy/organization they’re targeting is worth $10 million. Obviously there are other challenges that would be involved in attacking the torrent swarm like the fact that you’re not likely to have a sole seeder with corrupted checksums, and a naive implementation will almost certainly end up with a corrupted file instead of a working attack, but to someone with the resources and motivation to plan something like this it could get dangerous pretty quickly.

Supply chain attacks are increasingly becoming a serious risk, and we do need to start looking at upgrading security on things like the checksums we’re using to harden them against attackers, who are realizing that this can be a very effective and relatively cheap way to widely distribute malware.

I still use Nextcloud for syncing documents and other basic stuff that is relatively simple. But I started getting glacial sync times consuming large amounts of CPU and running into lots of conflicts as more and more got added. For higher performance, more demanding sync tasks involving huge numbers of files, large file sizes, and rapid changes, I’ve started using Syncthing and am much, much happier with it. Nextcloud sync seems to be sort of a jack of all trades, master of none, kind of thing. Whereas Syncthing is a one trick pony that does that trick very, very well.

I feel like you are the one who is confusing a “NAS device” or “NAS appliance” as in a device that is specifically designed and primarily intended to provide NAS services (ie, its main attribute is large disks, with little design weight given to processing, RAM or other components except to the extent needed to provide NAS service), and a NAS service itself, which can be provided by any generic device simultaneously capable of both storage and networking, although often quite poorly.

You are asserting the term “NAS” in this thread refers exclusively to the former device/appliance, everyone else is assuming the latter. In fact, both are correct and context suggests the latter, although I’m sure given your behavior in this thread you will promptly reply that only your interpretation is correct and everyone else is wrong. If you want to assert that, go right ahead and make yourself look foolish.

Yes, you could probably use a laser furnace if it was cost-effective at those power levels. But it’s not even close. Arcs are and very practical in almost every sense and ridiculously cheap besides the power they consume. And a laser would consume more.

You can also automate this with autossh which is designed for exactly this kind of persistent tunnel. Although a simple “while” loop might seem like the intuitive way to keep it running, autossh is very reliable and takes care of all the corner cases for you.

DC adds an extra layer of isolation if something goes wrong, and an extra place for it to fail safely in a nicely enclosed metal box. It takes a really catastrophic failure for a 28A DC power supply to go much beyond 28A for very long. A mains supply can do it all day long unless there’s some other form of protection like a fuse or isolation transformer.

It is mostly a myth (and scare tactic invented by copyright trolls and encouraged by overzealous virus scanners) that pirated games are always riddled with viruses. They certainly can be, if you download them from untrustworthy sources, but if you’re familiar with the actual piracy scene, you have to understand that trust is and always will be a huge part of it, ways to build trust are built into the community, that’s why trust and reputation are valued higher than even the software itself. Those names embedded into the torrent names, the people and the release groups they come from, the sources where they’re distributed, have meaning to the community, and this is why. Nobody’s going to blow 20 years of reputation to try to sneak a virus into their keygen. All the virus scans that say “Virus detected! ALARM! ALARM!” on every keygen you download? If you look at the actual detection information about what it actually detected, and you dig deep enough through their obfuscated scary-severity-risks-wall-of-text, you’ll find that in almost all cases, it’s actually just a generic, non-specific detection of “tools associated with piracy or hacking” or something along those lines. They all have their own ways of spinning it, but in every case it’s literally detecting the fact that it’s a keygen, and saying “that’s scary! you won’t want pirated illegal software on your computer right?! Don’t worry, I, your noble antivirus program will helpfully delete it for you!”

It’s not as scary as you think, they just want you to think it is, because it helps drive people back to paying for their software. It’s classic FUD tactics and they’re all part of it. Antivirus companies are part of the same racket, they want you paying for their software too.

Keep the gray plastic. Remove black clip around the vertical wheel post in the gray plastic. Remove wheel and wheel post. Buy new wheel. Installl new wheel. It will be easier to find a new wheel once you have the old wheel out so you can take measurements. but it’s likely something pretty standard, off-the-shelf. Wheels are something that companies buy, they rarely build them themselves. They typically come as a castoring assembly with wheel, axle, spindle, and attachment post in a variety of common sizes and with a dizzying variety of actual wheels.

Clearly Russia has no idea how to censor different things in different ways to create a specific narrative for people to buy into. They’ve never done anything like that before, they aren’t masters of the craft of disinformation or anything.

Totally unrelated joke, how do you know if a Russian is lying? You don’t, sometimes he could be telling the truth just to trick you.

And I’ll throw in one of my favourite exchanges between two characters:

“Of all the stories you told me, which ones were true and which ones weren’t?” “My dear Doctor, they’re all true.” “Even the lies?” “Especially the lies.”

Trusting something coming out of Russia to be true is foolish, just as foolish is trusting it to be false. Nothing that say is reliable in the slightest or should be used to make any useful conclusion about the real world.

That’s what LCARS means, it’s the name of the computer console in Star Trek. In the show, it stands for “Library Computer Access and Retrieval System” although it’s often used for stuff other than the library computer too.

a) Forecasts are very resource-intensive, they are performed on a specific schedule using a computational forecast model. Updating the predictions would require inputting new data and running the model again, and by the time they do that, the next forecast will already be out.

b) Do they know it’s wrong? Where did you get the temperature? From an official weather station? If not, there is no reason to imagine that someone is noticing that this one particular model run was wrong in one particular spot across the whole country and trying to fix it in real time.

c) If you did get the current temperature from an official weather station, that IS your update for it. Real time data from official weather stations is always going to trump the forecast model. What would be the point of updating the forecast when the current measured data from the weather station is now available? That’s like driving down the highway and saying “I was predicting my speed would be close to 65mph, but due to the heavy traffic I’m seeing today, I’m going to re-estimate my speed to be 45mph” when you have a perfectly accurate speedometer right in front of you telling you exactly what speed you are going at all times. Forecasts are only useful for the future, and they can be wrong.

Almost like the context matters and the world isn’t entirely made up of black and white binary choices because we’re not robots or computers and discrete logic does not apply to human moral arguments.

It’s the difference between your friend making you a cup of tea, and Putin making you a cup of tea.

They’re only lying as long as people can continue to over and over find their way around the obstacles they place in the way, and it gets harder all the time. They have more money and more resources and more organization than the hackers trying to defeat them, they’re winning the war of attrition. We may be able to make small breakthroughs here and there, but overall we continue to lose more and more territory, because the amount of effort is disproportionate to the goals. Most of what’s left of the custom ROM community has given up on the losing battle with manufacturers and providers and changed focus to the various freephones but even they have their own troubles and are fragmented and short-lived. Between carriers, manufacturers, and content providers the whole mobile ecosystem is designed to be impenetrable. It is intentionally a fortress full of deadly traps and open source supporters have no hope to breach it anytime soon.

Never had a single functional problem with Nextcloud, other than the fact that it’s oppressively slow with the amount of files I’ve shoved into it. Mind you I also don’t use MySQL/MariaDB which I consider a garbage-tier DB. Despite Postgres not being the “Recommended DB” for Nextcloud it works perfectly for me. Maybe that’s the difference.

Nah, I wanted to love NixOS, and granted it seems like a perfect fit for my recommendation, but a bunch of things about it rub me the wrong way. It’s just not for me. I’ve always been most comfortable with Debian and that’s what my setup script is designed for. Lots of apt.

Nuclear weapons in the current era of mutually assured destruction are strictly a deterrent, only useful in a hypothetical retaliatory strike but not as a realistic offensive weapon. The hypothetical situation where this would hypothetically be used would be after Seoul has fallen to the enemy and defeat is inevitable. By having such an ability, this makes it very unattractive for any enemy to try to conquer and fortify Seoul or put any existential pressure on South Korea by any means, since doing so enables the use of a retaliatory nuclear strike, since in such a hypothetical situation there is no chance of regaining Seoul left for South Korea to worry about. Therefore, as a consequence, Seoul is protected in a very material sense by a weapon that will never have to be used in any actual strike ever.

They may only be a deterrent but they continue to be an extremely convincing and effective one.

I would need to factory reset the whole server for that, which would be … highly inconvenient for me. It took me quite a long time to get everything working, and I don’t wanna loose my configuration.

This is your actual problem you need to solve. Reinstalling your server should be as convenient as installing a basic OS and running a configuration script. It needs to be reproducible and documented, not some mystery black box of subtle configurations you’ve forgotten about ages ago. A nice, idempotent configuration script is both convenient and a self-documenting system for tracking all the changes you’ve ever implemented on your server.

Once you can do that, adding whatever encryption you want is just a matter of finding the right sequence of commands, testing it (in another docker perhaps) and then running your configuration script to migrate your server into the desired state.