Engerek01, thanks for that. I don't think I've seen the "update-alternatives" with the "--install" option before. I know that Java is cross-platform (the programs I intend to run I created in Windows). But when I checked in Linux I found that the default version is 11 (confirming what you said), so I don't know if maybe I'll be able to run the programs without even installing version 8, but maybe not. I'll try running them in 11 first and then try to install 8 if that doesn't work. I hadn't realized that any version was installed by default.

Darvond, I haven't even seen the dnf command before. I just looked it up though, and as Engerek01 says, I don't know if that will work on Mint.

EDIT: Whoops, I almost forgot! I went back into Linux and found out some things:

- First of all, it has Java 11 pre-installed, so that might work with the programs I have to run. I'll try it, and if it doesn't then I'll install version 8.

- Secondly, I checked my network information while I was there, and it said that I have an Intel Ethernet I219-V with driver e1000e v 3.2.6-k, and a TP_Link 802.11ac NIC port efa0. One of them said vendor ASUSTeK, but I'm not sure what all applied to which thing (and I wrote some notes by hand). But it also said "No WAN IP found. Connected to the web? SSL issues?"

- Thirdly, I noticed while looking through the built-in programs on the start menu (or whatever it's called), there are several that look like they're for installing and/or decompressing various files, but I'm not sure which is used for what, or how to use them. If they save me from having to type in every time I want to use tar or gunzip or apt/apt-get or any of that stuff every time, they might be worthwhile. Anyway, there's "Software Manager", "Synaptic Package Manager", "Update Manager" and "Software Sources", so if anyone knows what any of these specifically are, or what the difference between them is, I'd be curious about that.

Thanks.

I did; one popped open a populated list of files automatically set up, the other made the point clear.

Welcome to hell, kid. Where instead of just sticking to the simple graphical package manager, the kind people at Canonical decided instead to screw up multiple times.

So basically, Synaptic is for dealing with the software packages directly. Instead of opening a terminal and wrangling aptitude, you instead wrangle Synaptic. It has barely changed interface in over a decade, and it shows in the worst ways; the UX leaves a lot to be desired over DNFdragora or tkpacman.

One or two of those is probably some dangerous thing that comes with Cinnamon; though with those widely descriptive names, it can be nigh impossible to know, and is the bane of many a developer.

The Software Sources as far as I'd estimate to surmise is the place where because of the nature of the beast, you'd manage things like those hellbeasts called PPAs among other things. See, when Ubuntu or Debian doesn't package something, there isn't a central repository to put it like the AUR or COPR.

Instead they fall prey to the very thing you don't want to do, and that's leave the trust to Jon Q Random on his website to leave a package out in the open, with absolutely no fingerprint or security scrutiny. Also, Debian relies on manual mirror selection, which is always fun.

As for the matter of the Update Manager, that could be a simple shell for aptitude-update, or it could be something worse; such as an update manager that chooses to forgo the system packagages in favor of Flatpack or Hades help you, Snaps; formats which exist outside of the internal ecosystem with ugly hairs and snags. (Snaps being closed source is a big one, Flatpacks being insane about caching is another.)

Oh, right. Somewhere in there is probably a tool to do kernel management; a dangerous activity where instead of automatically keeping the latest kernel(s) installed, you could find yourself whole grades or points behind.

Great... so basically, I shouldn't use any of those tools, right?

Well if (as you said) all you need is a browser to browse the web and Java for something, then apt ought to get you there. No need for all these tools. If you want to do more, well, Linux *is* tool hell (or heaven if you're crazy enough to like them..). You won't get far without a pile of tools and many of them suck. Some of them suck more than others, but you use what you need.

Since it is about drivers for a wifi adapter, I guess they assume the person has internet through an ethernet cable. I guess you don't have that option.

It is not a requirement, but then you have to copy the drivers and any other required packages to the system with an USB stick or some other way.

If you are unable to locate your adapter on TP-Link homepages, one way to identify it (or at least the chipset it uses) is to google for the ID that you get with the lsusb command.

clarry, well if they'd only make the tools good then it wouldn't be necessary to rely on text for everything, and then maybe Linux would become more popular even for mainstream laymen. But I guess the programs are what they are, and if they suck then they suck, so I'll use the text interface like everyone else.

timppu, wow, thanks for the tip about lsusb! I just looked that up and it seems like a very good way to get information! I hope to try it tomorrow, but I'm about done for today.

Another approach is to check for the FCC ID number (it should be on a label somewhere on the adaptor) and do a search on it.

If security is a prime concern, then consider using an SD (Secure Digital) card plugged into a USB adaptor rather than a USB stick. SD cards (the full size ones - not the micros) contain a write protect slider switch, which you can set once you have everything set up and want to prevent further changes. Do a test write though, to verify the write protection, since it is rather easy not to slide the switch far enough.

The longer you use Linux, the more you tend to gravitate to doing most maintenance stuff etc. through the bash shell ("command prompt"), instead of graphical tools. Or, at least that has happened to me.

Most Linux instructions etc. online are presented with shell text commands because it is easier to present "give these exact three commands" than trying to explain with screenshots where you should navigate in a tool and what buttons to click.

Also, the graphical tools may be (=are) different in different Linux installations, so you'd first have to know what graphical tools the person is using, and be familiar with them. With text commands, there is much less variance.

SD card write protection is a lie. It's not actual write protection, just a signal that asks the software to pretty please don't write would you?

AstralWanderer, well actually, I was thinking of making the whole thing read-only after I have it set up exactly how I want, and then saving documents would have to be done on a different drive. I think I found a way to do that, but I'm not sure how exactly it would work on the main Linux installation partition, because you have to change a configuration file, but then what, it never lets you change it back again, because that would require writing to a file? So then basically it becomes impossible to ever undo the effect? That seems a little extreme.

timppu, those are very good points about different GUIs and the inconvenience of needing screenshots (or videos). I hadn't thought of that.

clarry, good to know.

Now I think I'll get the Java working, and then I'll get the info about my adapter, search for it, and possibly post it here, in hopes of figuring out exactly how to get the internet connected. See you in a bit...

What might be a good linux distribution to make a bootable pendrive?

I'm doing that very thing with Linux Mint. It can run in live mode (like a test mode for the installer without installing, so you can't save to it but you can save documents on other drives, but you can't change default configurations, I don't think), or you can actually install it directly onto another USB drive and then run it like the normal, full OS!

Anyway, I've hit a couple more snags:

First of all, I tried to run a Java program, and it said that it's not executable, and I'd have to change the permissions. I tried it two ways:

- First I opened the properties and checked the box to allow it to execute, and when I did that, it checked on for about half a second and then automatically unchecked again, and did that each time I tried!

- Then I used chmod to set the permissions to +rx, and it expected the sudo password, but then it didn't say anything (no error, so I thought it worked), but it still wasn't executable!

The other thing is that I've found the information from lsusb for my WiFi adapter, but I'm not sure how useful it actually is. First, here's what I got from inxi:

Network:
Device-1: Intel Ethernet I219-V driver: e1000e
IF: eno1 state: down
Device-2: TP-Link 802.11ac NIC type: USB driver: usb-network

And here's what I got from lsusb, but I don't see any specific model number other than 802.11ac, which I think is more of a generic internet protocol or something like that, if I'm not mistaken:

Bus 002 Device 002: ID 2357:012d TP-Link 802.11ac NIC
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x2357 TP-Link
idProduct 0x012d
bcdDevice 3.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0053
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 504mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 5
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 3
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x08 EP 8 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 3

Knowing the text tools is helpful in case you hose your system so badly that you can't load xorg or wayland, and therefore can't get a graphical environment. If the system is hosed so badly that you need to do something like init=/bin/sh, then all you'll have is the shell to work with until you fix things.

Also, Linux is commonly used on servers, which have different constraints than desktops:
* The server might be headless, in that it has no monitor or input devices other than the network connection.
* Running a GUI on a server is a waste, creates a bigger attack surface for security vulnerabilities.
* Exporting a GUI over the network uses a considerable amount of bandwidth (which may be at a premium if the server is also busy at the same time), while a text console takes very little bandwidth. (There's a reason that ssh, which allows secure remote command line access to a machine, is so popular!)

A similar situation arises with embedded Linux; you may not have the resources or the hardware to display a GUI on such systems.

Another thing is that it's much easier to write a program that runs from the command line than it is to write a full-fledged GUI program. For simple tasks, writing the GUI might take more effort than writing the main program logic! If it's a one-off program that you're writing for yourself, it's much easier to just run it from the command line.

Also, shells have some nice features, like redirecting the input and/or output to a file, piping one program's output to another's input, and you can put commonly used sequences of commands into a shell script. In addition, shell scripting is its own language, with features like loops and background tasks, that is particularly well suited to running other programs.

So, I really do recommend that you learn the Linux shell; it's quite useful, and sometimes you do need to use it.

In Linux, you have the option of mounting partitions read-only, and the kernel will enforce that. Just modify the entry for the partition in /etc/fstab to add the "ro" option (and remove "rw"), and at boot the filesystem will be mounted read-only. (Note that some parts of the filesystem do need to be writeable; you may need to put them on other partitions, or use tmpfs for anything whose contents you don't care about saving (like /tmp), assuming you have enough RAM.

Also, you can change the filesystem back to read-write while it's running with a mount command that looks something like this:
# mount -o remount,rw /

(The "#" indicates that the command needs to be run as root; on modern Linux desktops, this is usually done be prepending the command with "sudo", then entering your user password at the prompt. Also, you will need to remove the "#", or else the command will not be executed, as the shell will treat it as a comment.)

That's because compiled java programs are not Linux executable files, so the kernel doesn't know how to execute them. There are two ways to run a Java program in this situation:
1. Use the "java" command to start the program. (If it's not installed, you'll need to install it. Try looking at packages that have "openjdk" in their names ("apt search openjdk" on debian-based systems) for a suitable one. This is by far the easier method (unless the distro sets up the second method for you).
2. Tell the kernel how to execute Java files. This will involve looking at the "binfmt-misc" kernel module. This is the harder method, and I have not done this manually, so I can't offer advice here.