And will be cancelled in 18 months with 2 weeks notice.

Awesome. Now stick with it!

And remember, different isn't wrong, it's different.

If you weren't at a university it was generally a challenge to get hold of disks. Downloading at home took forever on a 28.8 or even 56k modem (ie. 56 kilobits per second).

Slackware and Redhat disk sets were the thing, in my experience. But generally that only gave you the compiled code, not the source (although there was an another set of disks with the source packages).

If you wanted to recompile stuff you had to download the right set of packages, and be prepared to handle version conflicts on your own (with mailing list and usenet support).

Recompiling the kernel with specific patches for graphics cards, sound cards, modems and other devices (I remember scanners in particular), or specific combinations of hardware was relatively common. "Use the source, Luke!" was a common admonition. Often times specific FAQ pages or howtos would be made available for software packages, including games.

XFree86 was very powerful on hardware it supported, but was very finnicky. See the other posts about the level of detail that had to be supplied to get combinations of graphics cards and monitors working without the appearance of magic smoke.

Running Linux was mostly a enthusiast/hobbyist/geek thing, for those who wanted to see what was possible, and those who wanted to tinker with something approaching Unix, and those who wanted to stretch the limits of what their hardware could do.

Many of those enthusiasts and hobbyists and geeks discovered that Linux could do far more than anyone previously had been prepared to admit or realise. They, and others like them, took it with them into progressively more significant, and valuable projects, and it began to take over the world.

Consider using tar to create an archive of your home directory, and then unpacking that on the new machine. This will help to capture all the links as well as regular files, and their permissions.

Take a minute to think what else you have changed on the old machine, and then take another minute to think how tricky it would be to replicate on a new machine. Downloading the apps again is gloriously easy. Replacing configs, or keys and certificates, is not!

I normally archive /etc as well, and then I can copy out the specific files I need.

Did you install databases? You'll want to follow specific instructions for those.

Have you set up web sites? You'll want to archive /var/www as well.

Time to blades a new trail.

Waiting to find out the reasons for the premature shutdowns, and for pics of the steel plates...

Great to see the test campaign swing back into action!

Eric Berger has posted a mostly positive review of the test on Ars Technica.

Experimenting with VMs is the way forward.

Basic networking knowledge is vital. And being able to configure your own firewall(s) safely is an important skill. Check out something like Foomuuri, or Firewald. Shorewall is brilliant for documentation and description of issues (with diagrams!) but it does not use the newer Linux kernel nftables and is no longer actively developed.

Go for it with Nextcloud.

I would also recommend at least having a shot at setting up an email server, although I would recommend pushing through to a fully working system. It is possible, and is very satisfying to have in place. The process of setting one up touches so many different parts of internet function and culture that it is worth it even if you don't end up with a production system. The Workaround.org ISPMail stuff is a good starting point, and includes some helpful background information at every stage, enough so you can begin to understand what's going on in the background and why certain choices are being made - even if you disagree with the decisions.

Python is great for server admin, although most server config and startup shutdown snippets are written in BASH. You will no doubt have already begun picking that up as you interact with your VMs.

I think such a dataset would be very useful. I'm just getting in to 3D printing and have spent a little bit of time hunting for this type of information already. I've had to stick to star ratings on vendor sites so far.

• What are the physical properties it would be useful to track?
• How are they measured/which standard is being followed?
• How do they relate to practical matters like ideal extruder temperature and velocities for particular properties or effects?

(Edit: typo)

I have never knowingly used Arch. Am I allowed to like this song?

Also, Taylor Swift, is that you?

SSH along with the extra stuff it comes with like scp is the way forward.

The two following suggestions make use of secure shell.

Termux and then pkg install mc (MC is Midnight Commander)

Alternatively, if you are feeling brave and GUI, Total Commander here.

Thanks for the tip! Will check them out.

I came here to upvote the post that mentions haproxy, but I can't see it, so I'm resorting to writing one!

Haproxy is super fast, highly configurable, and if you don't have the config nailed down just right won't start so you know you've messed something up right away :-)

It will handle encryption too, so you don't need to bother changing the config on your internal server, just tweak your firewall rules to let whatever box you have haproxy running on (you have a DMZ, right?) see the server, and you are good to go.

Google and stackexchange are your friends for config snippets. And I find the actual documentation is good too.

Configure it with certificates from let's encrypt and you are off to the races.

Check that it works with Klipper!

The convenience and control Klipper provides is phenomenal. You don't have to use it if it turns out you dont like it, but I feel like ruling it out as an option now would be a shame.

I would also point out that you should not be put off by the "official" supported printers list for Klipper, a bit of Googling will often turn up some mini projects where people are actively working on supporting the printer with Klipper before the main project gets round to adding official support.

Roll on to this time next year with the following headlines...

FAA: discovers burning RP1 is bad for the environment, insists SpaceX must begin deployment of methane fueled rockets.

And

FAA: does not insist on development of methane fueled large aircraft.

And

FAA investigators complain they cannot get close enough for long enough to investigate SpaceX launchpad before another rocket launches

And

Unusually high number of FAA personnel reporting hearing problems.

Is this just the backend, or is it UI too? Is there an easy way to find this out myself in future?

Working here (UK).

I cut my teeth on an early version of The Linux Networking Howto, still available at tldp.org. That's a little bit out of date now :-) but the basic IPv4 networking concepts are still good.

These days so much is implementation or distribution dependent. There has been so much very rapid development in this field during the internet era that the age of documentation matters significantly.

A mitigating, but also confusing, factor is that different generations of networking tools have backwards compatibility built in so that it has been possible to build firewalls on kernels running nftables using iptables utilities in userspace.

I think you could do worse than starting with the Debian wikis and then drilling down into other documentation for the specific distributions or applications you want to use.

I seem to remember that openwrt.org and shorewall.org (though that product is EOL) also have some good overarching network stuff. I think Hurricane Electric he.com may still do their free basic IPv6 certificate programme?

Wikipedia is also your friend in this, especially the references.

I've enjoyed onemarcfifty.com's videos too, but that format isn't what you are looking for, and the transcripts I have seen are not formatted.

Windows 98

People not so much leaving the country as switching their advertising tracker?