Windows – Change memory size units in Windows 10

My previous understanding is that all information was stored in a binary form (0s and 1s) on hard drives, and in blocks of 8-bits, in modern computer hard drives. And that hexadecimal is utilized to facilitate the display of information, so humans aren't required to read through long blocks of bits.

That's 100% correct. Hexadecimal is merely a representation of data; there's nothing special about the nature of hexadecimal compared to other formats. It doesn't enable data compression or anything like that.

I think what your friend was referring to is the difference between representing numbers as character strings versus representing numbers as numbers.

For unsigned integers -- which is a representation of numbers in bits (zeroes and ones) from 0 to a certain, fixed, maximum number -- the maximum number that can be represented by N bits is 2^N, minus 1, assuming you start with 0.

So, if you have 8 bits (a.k.a. 1 byte), you can represent every number from 0 to 255 without losing information; you can manipulate these eight bits between 0 and 1 to unambiguously represent every number from 0 to 255, inclusive. Or from 1 to 256, if you prefer. It doesn't matter. Computers tend to represent them starting from 0, though.

If you have 16 bits (2 bytes), you can represent every number from 0 to 65535 (that's 2^16 - 1). 32 bits, every number from 0 to 4294967295. 64 bits, every number from 0 to a number that's 1.8 with nineteen zeroes.

You might know from algebra that 2^N is an exponential function. That means that, even though 64 bits is only eight times more bits than 8 bits, it can store way, way, way more data in that 8-times-more-bits than the number 255*8 (which is only 2040!). 2040 is a very small number compared to approximately 180000000000000000000. And 64 bits can store EVERY number from 0 all the way up to that maximum.

One interesting implication of integers stored in this way is that the programmer must decide in advance how big the storage needs to be, which in turn, determines the maximum number that can be represented by a given integer. If you try to store a number bigger than the storage can handle, you get something called overflow. This happens, for example, if you have an 8-bit integer, that's set to 255, and you ask the computer to add 1 to it. Well, you can't represent 256 within an integer whose range is 0 to 255! What usually happens is it "wraps around" back to the start, and goes back to 0.

There are programs that perform math in a mode called "arbitrary-precision" that automatically resize their storage to grow bigger and bigger depending on how big the numbers being handled are; for example, if you multiplied 255 by 100000, the answer would have to grow beyond 8 bits, and beyond 16 bits, but would fit within a 32-bit integer. If you input a number or performed a math operation that produced a number larger than the maximum for a 64-bit integer, it would have to allocate even more space for it.

HOWEVER -- if you represent numbers as a character string, then each number will take up as much space as a letter in written prose. "ASDF" and "1234" take up exactly the same space. "OneTwoThreeFourFive" (19 characters) takes up the same space as "1234567890123456789". The amount of space required grows linearly with the number of numbers (or letters, or characters, generically) you have. That's because each character can represent any of a myriad of characters within the character set, and numbers are just characters in a character set. A specific sequence of zeroes and ones will produce the number "3", a different sequence will produce "4", etc.

Typically characters are stored taking up either 8 or 16 bits, but some character encodings either take up a variable number of bits depending on the character (like UTF-8), or always take up a larger number of bits (like UCS-32).

If each character takes 8 bits, "OneTwoThreeFourFive" and "1234567890123456789" both take up 152 bits. But "1234567890123456789" can fit within a 64-bit unsigned integer, which... only consumes 64 bits. That's a savings of 88 bits! And we didn't even use any "data compression" tricks like Zip, 7-Zip, RAR, etc.

Some Linux distributions have a so called SELinux implementation in its kernel. It stands for "Security-Enhanced Linux" and, beside other things, restricts Samba shares. If you want to create a share folder then it's not not enough to specify convenient access permissions and a definition in samba.conf. You also need to set the correct "Security Context" of the share folder.

Following permission mask and security context should do the trick:

chmod -R 770 yoursharefolder
chcon -R -t samba_share_t yoursharefolder

All conditions that are already known from different wikis must also be adhered:

• Unix user as owner of the share must be added to Samba user database: smbpasswd -a youruser
• Your windows machine must have a user with the same name and same password as set in Samba database
• Your samba.conf may look like this:

samba.conf (all upper-case parts must be customized for your concerning specific environment):

[global]
workgroup = SAME_WORKGROUP_AS_CONFIGURED_IN_WINDOWS
server string = Samba Server %v
netbios name = HOST_NAME_OF_YOUR_LINUX_MACHINE_ON_NETWORK
security = user
map to guest = bad user
dns proxy = no

[yourshare]
path = /PATH/TO/YOURSHARE
valid users = YOUR_WINDOWS_USER_NAME
browsable = yes
writeable = yes
guest ok = no
read only = no
directory mask = 0770
create mask = 0770

Edit: Note that changes via chcon aren't permanent. In order to do permanent security context changes use following command:

semanage fcontext -a -t samba_share_t /full/path/to/your/share/folder

...and to make it effective:

restorecon -v /full/path/to/your/share/folder