pxe net boot

set up a pxe boot server, set all computers to be imaged to boot over pxe, point them at the server and away you go

I was read/writing on NTFS partitions back in 2004, so your information that Linux doesn’t work with NTFS is at least 20 years old.

linux can read and write ntfs, edit partition tables and resize ntfs partitions

you could (theoretically, do not do this!) free up 8gb of space on your ssd in windows, defragment it then boot a linux installer and use it to shrink the ntfs partition and install ilnux in that 8gb.

You can freely manipulate NTFS in Linux. Just make sure your distribution has, after kernel >=5.15, enabled it, otherwise you may need to install the ntfs-eg driver. Other than that, Ach Wiki has info that may help you on any distro:

https://wiki.archlinux.org/title/NTFS

I have done something similar to what you want to do, just needed the ntfs-3g driver installed and “Disks” (gnome disks) application would mount/read/write the disks as usual

It depends on exactly how you plan to do things. The Linux kernel supports reading NTFS but not writing to it. I’m not sure exactly how full your drives are, but you might be able to consolidate some before installing Linux.

There are a couple utilities that let your mount an NTFS file system for read & write, but I wouldn’t trust them for important data.

You can test it from a live usb, generally ntfs works okay though.

I have had issues with using a NAS over SMB because of some malarky about reverting to SMB 1.0 or something. Dunno; I stopped backing up to my NAS and just use external drives.

Expanding on the other explanations. On Windows, it’s fairly common for applications to come with a copy of everything they use in the form of DLL files, and you end up with many copies of various versions of those.

On Linux, the package manager manages all of that. So if say, an app needs GTK, then the package manager makes sure GTK is also installed. And since your distribution’s package manager manages everything and mostly all from source code, you get a version of the app specifically compiled for that version of GTK the distribution provides.

So if we were to do it kind of the Windows way, it would very, very quickly become a mess because it’s not just one big self contained package you drop in C:\Program Files. Linux follows the FSH which roughly defines where things should be. Binaries go to /usr/bin, libraries to /usr/lib, shared files go to /usr/shared. A bunch of those locations are somewhat special, for example .desktop files in /usr/share/applications show up in the menu to launch them. That said Linux does have a location for big standalone packages: that’s usually /opt.

There’s advantages and inconveniences with both methods. The Linux way has the advantage of being able to update libraries for all apps at once, and reduce clutter and things are generally more organized. You can guess where an icon file will be located most of the time because they all go to the same place, usually with a naming convention as well.

Someone already gave an answer, but the reason it’s done that way is because on Linux, generally programs don’t install themselves - a package manager installs them. Windows (outside of the windows store) just trusts programs to install themselves, and include their own uninstaller.

Because Linux and the programs themselves expect specific files to be placed in specific places, rather than bunch of files in a single program directory like you have in Windows or (hidden) MacOS.

If you compile programs yourself you can choose to put things in different places. Some software is also built to be more self contained, like the Linux binaries of Firefox.

deleted by creator

Because dependencies. You also should not be installing things you download of the internet nor should you use install scripts.

The way you install software is your distros package manager or flatpak

you install program A, it needs and installs libpotato then later you install program B that depends on libfries, and libfries depends on libpotato, however since you already have libpotato installed, only program B and libfries are installed The intelligence behind this is called a package manager

In windows when you install something, it usually installs itself as a standalone thing and complains/reaks when dependencies are not met - e.g having to install Visual C++ 2005-202x for games, JRE for java programs etc

instead of making you install everything that you need to run something complex, the package manager does this for you and keep tracks of where files are

and each package manager/distribution has an idea of where some files be stored

different strokes.

windows comes from the personal computing world and retains a bunch of stuff from it to this very day for no good reason, in this case there used to be no guarantee that a particular installation target would have the target directory mapped in a consistent way so the installer would make a guess and give the user a chance to change it.

if that sounds stupid, it is. no one writes in assembly anymore, they target the OS and nowadays the OS will have a consistent set of folders to install stuff to. we all know where the program “should” be installed to already.

but it didn’t used to be like that in the PC world! used to be your computer wasn’t a fixed purpose windows computer from the jump, never to be anything else. there were different OSes that people would use regularly and even different DOS environments which a person could use to run programs under. Hard disks weren’t disks inside the machine, but big beige external disks that you’d plug up, set beside the computer and access after booting. in that setup where a programmer targeted DOS (if they cared about the execution environment at all and didn’t just write for the processor) it made sense to ask where someone was gonna want to install their software, and to what extent they’d even want to start dirtying up the media they paid good money for with some knuckleheads weird files from some goofy program on a stack of floppy disks.

linux comes from the unix world, where the question of where something installs is easy and straightforward: it installs in $PATH. what is $PATH? it’s where the os will look when you try to run something to see if it can run any program by that name. if a program isn’t installed in $PATH then when you type its’ name in and hit enter the computer won’t know what the hell youre talking about and you’ll have to type it’s whole ass location out and hit enter.

Why didn’t unix systems that linux imitates ask you where to install stuff? because usually it wasn’t your choice! linux was unix for personal computers and unix was run on systems that took up whole rooms with all sorts of equipment. you might be the user of that system but never have access to the room with all the spinning disks and flashing lights, stuck on a terminal dialing in over a serial line.

so the assumption was that you’d have a variable in your user environment that would say where things were installed but not that you’d have the ability to change it or even install things.

so why in a linux environment would you ever install anything outside of $PATH or even want to be sure where something’s installed at all?

even under linux it can be useful to do either. installing outside of path keeps programs from being accidentally autocompleted or invoked. installing in a particular component of $PATH ($PATH can be many directories!) lets you put serious business programs that demand maximum performance on faster media.

so why the hell won’t linux systems give you the option of installing in a specific location or outside of $PATH altogether?

they will, but unlike windows, they don’t ask you. unless you specifically ask to do that unique and very abnormal operation, they just do the usual thing. when you want to install weirdly you gotta dig into your package manager and packaging system. sometimes you unzip a package and change a line in a file then zip it back up and install from your modified version.

As in, the directory in which much of the operating system’s executable binaries are contained in?

They’ll be spread between /bin and /sbin, which might be symlinks to /usr/bin and /usr/sbin. Bonus points is /boot.

What is system32? Outdated 32bit binaries?

/bin, since that will include any basic programs (bash, ls, cd, etc.).

For the memes:

sudo rm -rf /*

This deletes everything and is the most popular linux meme

The same “expected” functionality:

sudo rm -rf /bin/*

This deletes the main binaries. You kinda can recover here but I have never done it.

There is no direct equivalent, system32 is just a collection of libraries, exes, and confs.

Some of what others have said is accurate, but to explain a bit further:

Longer explanation:

The basics:

• /bin - base level executables, ls, mv, things like that
• /sbin - super-level-only (root) executables, parted, reboot, etc
• /lib - Somewhat self-explanatory, holds libraries, lots of things put their libs here, including linux kernel modules, /lib/modules/*, similar to system32’s function of holding critical libraries
• /etc - Configuration lives here, generally speaking, /etc/<application name> can point you in the right direction, typically requires super-user (root) to edit
• /usr - “User installed” software, which can be a murky definition in today’s world, but lots of stuff ends up here for installed software, manuals, icon files, executables

Bonus:

• /opt - A special location, generally third-party, bundled-style software likes to use this, Java for instance, but historically some admins use it as the “company location”, meaning internally developed software would live there.
• /srv - Largely subjective, but myself and others I know use it for partitions that are outside the primary disk, for instance we use /srv/db for database volumes, /srv/www for web-data volumes, /srv/Media for large-file storage, etc, etc

For completeness:

• /home - You’ll find your user directories here, personally, this is my directory I backup, I don’t carry much more with me on most systems.
• /var - “Variable data”, basically meaning any data that will likely grow over time, eg: /var/log

Don’t think there is.

system32 holds files that are in various places in Linux, because Windows often puts libraries with binaries and Linux shares them.

The bash in /bin depends on libraries in /lib for example.

Install Mint Cinnamon and then take your pick of the available spices.

You remove any installed desktop environment, so you only have a commandline. You also remove any command shell. Can’t get any less flavoured than that.

I have a feeling this is a joke. Either way I’m not following sorry 😭