aard

Technically the notation with dashes is the non-standard one - the dash form is a GNU addition. A traditional tar on something like Solaris or HP-UX will throw an error if you try the dash notation.

You also don't need the dash for the short options.

Also, if you're compressing with bzip2 and have archives bigger than a few megabytes I'll like you a lot more if you do it with --use-compress-prog=pbzip2

Danke fuer den Hinweis.

Nurmijarvi ist die Stadt nebenan, das koennte heute Abend was werden.

edit

War gut sichtbar, bis ich das Stativ fuer die Kamera gefunden habe wars aber weitgehend vorbei.

I'm running both physical hardware and cloud stuff for different customers. The problem with maintaining physical hardware is getting a team of people with relevant skills together, not the actual work - the effort is small enough that you can't justify hiring a dedicated network guy, for example, and same applies for other specialities, so you need people capable of debugging and maintaining a wide variety of things.

Getting those always was difficult - and (partially thanks to the cloud stuff) it has become even more difficult by now.

The actual overhead - even when you're racking the stuff yourself - is minimal. "Put the server in the rack and cable it up" is not hard - my last rack was filled by a high school student in a part of an afternoon, after explaining once how to cable and label everything. I didn't need to correct anything - which is a better result than many highly paid people I've worked with...

So paying for remote hands in the DC, or - if you're big enough - just order complete racks with racked and pre-cabled servers gets rid of the "put the hardware in".

Next step is firmware patching and bootstrapping - that happens automatically via network boot. After that it's provisioning the containers/VMs to run on there - which at this stage isn't different from how you'd provision it in the cloud.

You do have some minor overhead for hardware monitoring - but you hopefully have some monitoring solution anyway, so adding hardware, and maybe have the DC guys walk past and inform you of any red LEDs isn't much of an overhead. If hardware fails you can just fail over to a different system - the cost difference to cloud is so big that just having those spare systems is worth it.

I'm not at all surprised by those numbers - about two years ago somebody was considering moving our stuff into the cloud, and asked us to do some math. We'd have ended up paying roughly our yearly hardware budget (including the hours spent on working with hardware we wouldn't have with a cloud) to host a single of one of our largest servers in the cloud - and we'd have to pay that every year again, while with our own hardware and proper maintenance planned we can let old servers we paid for years ago slowly age out naturally.

The encryption tech in many cloud providers is typically superior to what you run at home to the point I don’t believe it is a common attack vector.

They rely on hardware functionality in Epyc or Xeon CPUs for their stuff - I have the same hardware at home, and don't use that functionality as it has massive problems. What I do have at home is smartcard based key storage for all my private keys - keys can't be extracted from there, and the only outside copy is a passphrase encrypted based64 printout on paper in a sealed envelope in a safe place. Cloud operators will tell you they can also do the equivalent - but they're lying about that.

And the homomorphic encryption thing they're trying to sell is just stupid.

Overall, hardened containers are more secure vs bare metal as the attack vectors are radically diff.

Assuming you put the same single application on bare metal the attack vectors are pretty much the same - but anybody sensible stopped doing that over a decade ago as hardware became just too powerful to justify that. So I assume nowadays anything hosted at home involves some form of container runtime or virtualization (or if not whoever is running it should reconsider their life choices).

My point is that it is simpler imo to button up a virtual env and that includes a virtual network env

Just like the container thing above, pretty much any deployment nowadays (even just simple low powered systems coming close to the old bare metal days) will contain at least some level of virtual networking. Traditionally we were binding everything to either localhost or world, and then going from there - but nowadays even for a simple setup it's way more sensible to have only something like a nginx container with a public IP, and all services isolated in separate containers with various host only network bridges.

I think quite a few countries would see "kicking you out whilst battling cancer" as a human rights violation, and would only kick you out after your treatments.

I was searching for some precedent there - which brought up Bush eliminating cancer treatments for illegal immigrants in 2007. It's impressive that this war criminal can still disgust me even further.

Depends on what you mean by "child friendly". On my instance I control discoverability of channels as well as the bridges to other protocols. If that is fine for you I don't see a problem with a public instance - just make sure to set up encryption and save the recovery keys somewhere (at least for older children where they can control access).

Well with bare metal yes, but when your architecture is virtual, configuration rises in importance as the first line of defense

You'll have all the virtualization management functions in a separate, properly secured management VLAN with limited access. So the exposed attack surface (unless you're selling VM containers) is pretty much the same as on bare metal: Somebody would need to exploit application or OS issues, and then in a second stage break out of the virtualization. This has the potential to cause more damage than small applications on bare metal - and if you don't have fail over the impact of rebooting the underlying system after applying patches is more severe.

On the other hand, already for many years - and way before container stuff was mature - hardware was too powerful for just running a single application, so it was common to have lots of unrelated stuff there, which is a maintenance nightmare. Just having that split up into lots of containers probably brings more security enhancements than the risk of having to patch your container runtime.

Encryption is interesting, there really is no practical difference between cloud vs self hosted encryption offerings other than an emotional response.

Most of the encryption features advertised for cloud are marketing bullshit.

"Homomorphic encryption" as a concept just screams "side channel attacks" - and indeed as soon as a team properly looked at it they published a side channel paper.

For pretty much all the technologies advertised from both AMD and intel to solve the various problems of trying to make people trust untrustworthy infrastructure with their private keys sidechannel attacks or other vulnerabilities exist.

As soon as you upload a private key into a cloud system you lost control over it, no matter what their marketing department will tell you. Self hosted you can properly secure your keys in audited hardware storage, preventing key extraction.

Regarding security issues, it will depend on the provider but one wonders if those are real or imagined issues?

Just look at the Microsoft certificate issue I've mentioned - data was compromised because of that, they tried to deny the claim, and it was only possible to show that the problem exists because some US agencies paid extra for receiving error logs. Microsofts solution to keep you calm? "Just pay extra as well so you can also audit our logs to see if we lose another key"

I have a matrix instance in my garage we're using as family chat. My 7 year old gets along well with schildichat.

Listing Microsoft cloud after their recent certificate mess is an interesting choice.

Also, the "cloud responds to vulnerability" only works if you're paying them to host the services for you - which definitely no longer is self hosting. If you bring up your own services the patching is on you, no matter where they are.

If you care about stuff like "have some stuff encrypted with the keys in a hardware module" own hardware is your only option. If you don't care about that you still need to be aware that "cloud" or "VPS" still means that you're sharing hardware with third parties - which comes with potential security issues.

Interesting, I never encountered that - though that also fits the "2.5 decades" timeframe.

It still shows the author of the error message has no idea about networking: even if we assume network classes apply to RfC 1918 addresses (which they don't) the majority of those addresses are class A or class B networks.

And looking at it the other way round (using "class C" synonymous with "private addresses) doesn't work - the majority of addresses in class C space are public addresses.

I just took my cat to the petrol station to give it a try, and have to report that not only does she not have any indicators like this, she also was vehemently opposed to being refuelled and scratched me up badly.