97
short question by an aspiring user
(lemm.ee)
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
He didn't imply that, he said he wanted to format C:\
Why is it oversimplifying to say the disk will be called / in Linux?
I just meant with the
C:
comment that OP shouldn't expect it to still be calledC:
after he's wiped Windows and is running Linux.As for the oversimplification comment:
First off,
C:
(orD:
,E:
etc) doesn't refer to a disk in Windows. It refers to a partition. So it's entirely possible (and not terribly uncommon) to have a single disk with both aC:
and aD:
on it.It's very typical for a Linux installation process to (by default, if you don't tell it to do something else) make separate partitions on a single disk for
/
and/home
. (Plus there's usually an extra EFI boot partition on most modern desktop/laptop systems. And a swap partition.) In such a case, you couldn't really describe where "the disk" (that was formerly calledC:
on Windows) was mounted in the mindset of conflating "partition" with "disk". What was previously "the disk"C:
(again,C:
isn't a disk, it's a partition, but Windows makes it easy to conflate the two) is now split in two (or three or more) and mounted not just on/
but also on/home
(and maybe on/boot
as well, and maybe one partition isn't mounted on the main abstract root filesystem)./
and/home
aren't really even partitions (let alone disks). They're mount points in the slightly more abstract root filesystem.The most obvious software representation on a typical Linux system of the main internal disk in that machine would probably be something like
/dev/sda
or/dev/nvme0
. The partitions would likely be something like/dev/sda1
//dev/sda2
/etc or/dev/nvme0p1
//dev/nvme0p2
/etc. Also, the "filesystem" on the partition is arguably a subtlely a distinct concept from the block device that is the partition. And where that filesystem is mounted is yet another distinct concept. (Another subtlety I haven't mentioned is the distinction between the device in the/dev/
directory/filesystem and the kernel representation of the device with the device major/minor numbers.)A typical Windows install kindof conflates a lot of these probably a lot more so than Linux does. But I didn't want to be like "akshuly things are a lot more complicated than that and you have to understand a bunch of Linux kernel internals to understand all the ways in which you're wrong so you can install the holy 'Guh-noo Plus Linux'." All that is stuff that OP will learn by installing and using Linux. And if OP's going with Mint, it's probably not necessary to really understand all of that before starting the install process.
And technically OP doesn't really need to understand that the main disk won't be called
C:
after switching to Linux. Probably. (I don't think I've ever installed Mint. So I don't know for sure, but from what I've heard about it, I'd be surprised if the installation process had much of a learning curve.) But I told OP anyway. So there. :DOkay thank you. I feel like it's a lot of information here that is about, like you say, how complicated abstract and advanced it is, with the devices, kernel representations and mount points.
There must be a better way of just explaining how the root fs works, because I still don't understand anything.
It really doesn't feel like comparing it to windows gives any favours though, maybe explain use cases, like where would the user save downloads, where would you install apps?
I've used Linux a little. Right now it's modernized enough for me to not learn the file system. But I remember in old times when I ran Ubuntu I just crammed files in a folder and struggled a lot with it
Ok. Lessee.
Just to quickly explain first off:
01100001
and later it can reliably be read back from the same index as the same value, until it's changed to a different value.)/dev
for the disk along with more files for each of the partitions on the disk. For instance, an external USB hard drive with three partitions might show up as/dev/sda
and the partitions as/dev/sda1
,/dev/sda2
, and/dev/sda3
respectively. (Ok. Technically the things in/dev
are only files in some senses. They're technically "devices". But they have paths like files do and they can be read from and written to like files.)/dev
a file lives on and what filesystem driver is used for that device, themount
command just typed into any bash terminal will tell you. It'll output rows likeon type (...)
. If you read/write a file or list a directory, it'll pick the entry in themount
output that has the longestthat is a prefix of the requested file. The
is the "file"(/device) in/dev
that corresponds to the parition on which that file is encoded. `` is the name of the filesystem driver. So, for instance, if I have an entry/dev/sdb3 on /mnt/pringles type ext4 (...)
and I read a file named/mnt/pringles/apple/unicorn/potato.txt
(and if there are no entries in themount
output with longer paths that are still prefixes of the requested file path), the kernel will ask theext4
filesystem driver to please look at the partition/dev/sdb3
and interpret that partition's contents as a hierarchical filesystem to find and return the contents of the file at the pathapple/unicorn/potato.txt
relative to the root of the filesystem encoded on the/dev/sdb3
partition.tmpfs
store data in RAM only (and RAM isn't intended to be persistent, so you can't expect anything in a tmpfs to last reliably through a reset.) Others likeprocfs
don't look at a disk but make these ephemeral files that basically decide what data to return when read from at the time they're read from. (Files inprocfs
filesystems usually expose data about the Linux system. Like, for instance, what processes are currently running.)Now, the question of where files should go is... kinda unrelated to the above. Files that are system-wide configuration should go in
/etc
. Files that are system-wide executables should generally go in/bin
,/sbin
,/usr/bin
,/usr/sbin
, and/usr/local/bin
. Anything your own user downloads/creates should go in/home/$username
. Etc. More specifics of all this here.It can be useful to make decisions regarding what disk/partition a particular directory like
/home
lives on. But whether/home
is on the same partition with/etc
and/bin
and/var
etc or whether it's on a different partition (and both of these options are quite common), your users' files should go somewhere in/home
.To elucidate a little more, if you decide to put your
/home
on the same partition as/bin
and/etc
and/var
and such, you'll have an entry in yourmount
output like/dev/sda2 on / type ext4
but nothing with a `` of/home
. If you decide to put/home
on a separate partition, you'll have your/dev/sda2 on / type ext4
entry plus another entry like/dev/sda3 on /home type ext4
.So which partition does a file go on when you write a file to
/home/keenflame/document.txt
? Well, in the first case, it'd be on the partition Linux calls/dev/sda2
. In the second case it would be written to the partition that Linux calls/dev/sda3
.