Windows drive letters are not limited to A-Z

All of those are optional restrictions, not mandatory. On Windows, it's (practically) mandatory.

Maybe some Windows wizards could get around the mandatory restrictions, but an average Linux user can get around the optional ones.

There is more pliability in the Linux ecosystem to change some of these things.

And anyway, there has to be a naming scheme; the naming scheme is abstracted from the storage scheme.

It's not the case that your /var and /usr are different drives; though it can be in a given installation.

Unix starts at root, which is how nature intended. It does not change characteristics based on media - you can mount a floppy at root if you want.

Why get upset over /media vs /mnt? You do you, I know I do.

For example The Step CA docs encourage using /etc/step-ca/ (https://smallstep.com/docs/step-ca/certificate-authority-ser...) for configuration for their product. Normally I would agree but as I am manually installing this thing myself and not following any of the usual docs, I've gone for /srv/step-ca.

I think we get enough direction from the ... "standards" ... for Unix file system layouts that any reasonably incompetent admin can find out which one is being mildly abused today and get a job done. On Windows ... good luck. I've been a sysadmin for both platforms for roughly 30 years and Windows is even odder than Unix.

/usr/bin vs /bin distinction is not relevant as all major distros have gone usrmerge for years now so /bin == /usr/bin (usually /bin is a symlink)

Ok, I prefer to use software which is future compatible, like ZFS, which is 128-bit.

“The file system itself is 128 bit, allowing for 256 quadrillion zettabytes of storage. All metadata is allocated dynamically, so no need exists to preallocate inodes or otherwise limit the scalability of the file system when it is first created. All the algorithms have been written with scalability in mind. Directories can have up to 248 (256 trillion) entries, and no limit exists on the number of file systems or the number of files that can be contained within a file system.”

https://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6qth/inde...

Don’t want to hit the quadrillion zettabyte limit..

Wait are you saying Linux broke user-space? I've completely missed this and would like to know more, may I be so bold as to request a link?

I don’t like running games from the early 2000s outside of a sandbox of some description. If you disagree, it's because we don't have sandboxes which don't suck. Ideally, running old software in a sandbox on a modern OS should be borderline transparent — not like installing XP in a virtual machine.

While I understand the appeal of software longevity, and I think it's a noble and worthy pursuit, I also think there is an under-appreciated benefit in having unmaintained software less likely to function on modern operating systems. Especially right now, where the concept of serious personal computer security for normal consumers is arguably less than two decades old.

Tim Patterson certainly copied it from CP/M and may not have been aware of anything predating it, but according to Wikipedia drive letters have quite a long history: https://en.wikipedia.org/wiki/Drive_letter_assignment

Come for punchcards, stay for legibility.

80 characters per line is an odd convention in the sense that it originated from a technical limitation, but is in fact a rule of thumb perfectly familiar to any typesetting professional from long before personal computing became widespread.

Remember newspapers? Laying the text out in columns[0] is not a random quirk or result of yet another technology limitation. It is the same reason a good blog layout sets a conservative maximum width for when it is read on a landscape oriented screen.

The reason is that when each line is shorter, the entire thing becomes easier to read. Indeed, even accounting for legibility hit caused by hyphenation.

Up to a point, of course. That point may differ depending on the medium and the nature of the material: newspapers, given they deal with solid plain text and have other layout concerns, limit a line to around 50 characters; a book may go up to 80 characters. Given a program is not a relaxed fireside reading, I would place it closer to the former, but there are also factors and conventions that could bring acceptable line length up. For example, indentation and syntax highlighting, or typical identifier length (I’m looking at you, CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter), or editor capability to wrap lines nicely[1].

Finally, since the actual technical limitation is gone, it is actually not such a big deal to violate the line length rule on occasion.

[0] Relatedly, codebases roughly following the 80 character line length limitation unlock more interesting columnar layouts in editors and multiplexers.

[1] Isn’t the auto-wrap capability in today’s editors good enough that restricting line length is pointless at the authoring stage? Not really, and (arguably) especially not in case of any language that relies on indentation. Not that it could not be good enough, but considering code becomes increasingly write-only it seems unlikely we will see editors with perfect, context-sensitive, auto-wrap any time soon.

If you don't have some level of arbitrary limit on line length, it becomes all that much easier to sneak in malicious code prefixed by a bunch of whitespace.

Linting and autoformats help here... just allowing any length of line in code is just asking to get pwned at some point.

> Of course software developers are still stuck with 80 column conventions

Speak for yourself, all my projects use at least 100 if not 120 column lines (soft limit only).

Trying to keep lines at a readable length is still a valid goal though, even without the original technical limitations - although the bigger win there is to keep expression short, not to just wrap them into shorter lines.

It did, but 80 columns also pretty closely matches the 50ish em/70ish character paragraph width that’s usually recommended for readability. I myself wouldn’t go much higher than 100 columns with code.

While 80 characters is obviously quite short, my experience is that longer line lengths result in much less readable code. You have to try to be concise on shorter lines, with better phrasing.

You can make harddrives to A: and B: just fine.

This will generally work with everything using the Win32 C api.

You will however run into weird issues when using .Net, with sudden invalid paths etc.

It really wouldn't be much of a conversation. Historical conventions are a thing in general. Just think of the direction of electron flow.

> even though we have 16x9 4K displays now

Pretty much no normal person uses those at 100% scaling though, so unless you're thinking of the fellas who use a TV for a monitor, that doesn't actually help so much:

- 100% scaling: 6 panels of 80 columns fit, no px go to waste

- 125% scaling: 4 panels of 80 columns fit, 64 px go to waste (8 cols)

- 150% scaling: 4 panels of 80 columns fit, no px go to waste

- 175% scaling: 3 panels of 80 columns fit, 274 px go to waste (34 cols)

- 200% scaling: 3 panels of 80 columns fit, no px go to waste

This sounds good until you need any additional side panels. Think line numbers, scrollbars, breakpoint indicators, or worse: minimaps, and a directory browser. A minimap is usually 20 cols/panel, a directory browser is usually 40 cols. Scrollbar and bp-indicator together 2 cols/panel. Line numbers, probably safe to say, no more than 6 cols/panel.

With 2 panels, this works out to an entire additional panel in overhead, so out of 3 panels only 2 remain usable. That's the fate of the 175% and 200% options. So what is the "appropriate" scaling to use?

Well PPI-wise, if you're rocking a 32" model, then 150%. If a 27" model, then 175%. And of course, given a 22"-23"-24" unit, then 200%. People of course get sold on these for the "additional screen real estate" though, so they'll instead sacrifice seeing the entire screen at once and will put on their glasses. Maybe you prefer to drop down by 25% for each of these.

All of this is to say, it's not all that unreasonable. I personally feel a bit more comfortable with a 100 col margin, but I do definitely appreciate when various files nicely keep to the 80 col mark, they're a lot nicer to work with side-by-side.

The fact that modern interactive command shells are based on virtual teletype terminals is just absurd when you think about it

Try explaining files to a kid these days

Didn't Microsoft drop 16 bit application support in Windows 10? I remember being saddened by my exe of Jezzball I've carried from machine to machine no longer working.

It's very impressive indeed.

Linux goal is only for code compatibility - which makes complete sense given the libre/open source origins. If the culture is one where you expect to have access to the source code for the software you depend on, why should the OS developers make the compromises needed to ensure you can still run a binary compiled decades ago?

My original VB6 apps (mostly) still run on win11

They've stopped caring as much about backwards compat.

Windows 10 no longer plays the first Crysis without binary patches for instance.

The 3.5mm audio jack is 75 years old, but electrically-compatible with a nearly 150-year-old standard.

Unix pre-dates floppy drives, at least on PDP-11.

Yep. NTVDM DLL too; it will run DOS binaries and some other stuff too. Also it has proper solitaires and such which you can just reuse by extracting the EXE files from the CAB file lying in the ReactOS live CD.

there are magical holding areas in Linux as well, but that detail is up to TLS libraries like openssl at run-time, and hidden away from their clients. There are a myriad of ways to manage just ca certs, gnutls may not use openssl's paths, and each distro has its own idea of where the certs go. The ideal unix-y way (that windows/powershell gets) would be to mount a virtual volume for certificates where users and client apps alike can view/manipulate certificate information. If you've tried to get a internal certs working with different Linux distros/deployments you might be familiar with the headache (but a minor one I'll admit).

Not for certs specifically (that I know of) but Plan9 and it's derivaties are very hard on making everything VFS abstracted. Of course /proc , /sys and others are awesome, but there are still things that need their own FS view but are relegated to just 'files'. Like ~/.cache ~/.config and all the xdg standards. I get it, it's a standardized path and all, but what's being abstracted is here is not "data in a file" but "cache" and "configuration" (more specific), it should still be in a VFS path, but it shouldn't be a file that is exposed but an abstraction of "configuration settings" or "cache entries" backed by whatever thing you want (e.g.: redis, sqlite, s3,etc..). The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.

This is nice! What I find hard to grapple with is, how do other concepts of the file system map to these providers, even more so to Alias, Environment, Function or Variable? Like creating an item, deleting an item, copying an item, viewing contents and properties like permissions, size, visibility of an item?

For the Certificate provider specifically: When I think certificates and hierarchy, I think signing hierarchy of issueing certs. But this is not what is exposed here, just the structure of the OS cert store without context. and moving items has much more implications that inside a normal data folder. Thus I prefer certlm/certmgr.msc as they provide some more of it.

Sometimes It feels as they crammed too much into that idea, a forced concept. https://superuser.com/q/1065812/what-is-psprovider-in-powers...

Other way around. Try mounting E: in your exfat drive.

Those weren't a consideration when the NT OS/2 Design Workbook was being written.

God mode shortcut: https://en.wikipedia.org/wiki/Windows_Master_Control_Panel_s...

I don't think it works that way, the actual drive letter is a UTF-16 Unicode path. The application must be able to provide an "ANSI" string that encodes to that UTF-16 value if it uses an "ANSI" function to open the file. It's not like 8-bit systems where they just want the same 8-bit value.

They're still actively used to apply the Mark of the Web to indicate a file has been downloaded from an untrusted zone and should be handled with caution. I believe macOS also applies similar metadata.

There are a few other places where they also show up, but the MotW is the most prevalent one I've found. Most antivirus programs will warn you for unusual alternate data streams regardless of what they contain.

That would only interact with the shell, as `%` is not actually part of the environment variable name, it's just a way to tell the shell you want it to get the value of an environment variable. The environment block itself is a NULL terminated list of NULL terminated WTF-16 strings of the format <key>=<value>, so `=` would be the more interesting thing to try.

And indeed, it looks like using `=` as a drive letter breaks things in an interesting way:

    =:\> cd bar
    Not enough memory resources are available to process this command.

    =:\bar>

With a program that dumps the NULL terminated <key>=<value> lines of the environment block, it looks like it does still modify the environment, but in an unexpected way:

Before `cd /D =:\`, I had a line that looked like this (i.e. the per-drive CWD for C:\ was C:\foo):

    =C:=C:\foo

    =C:==:\

    =:\foo> cd /D C:

    =:\>

You might also be interested to know that '= in the name of an environment variable' is a more general edge case that is handled inconsistently on more than just Windows: https://github.com/ziglang/zig/issues/23331

I don't recall this, and I do recall running something like "diskcopy A: A:" to do that operation.

While original IBM PCs indeed may not have had HDDs, it did become a standard for PC XT, as early as 1983. Only the cheapest version were without a HDD by the end of the 1980s.

When recordable CDs were brand new, we set up a station at work with two hard drives (C: and D:) and the CD burner (E:). Naturally, the CDR burning software was hard-coded for D: but didn't mention that anywhere (including the error message). Took us a few hours to figure it out.

"That's why D was typically the CD-ROM:"

We used to set our machines so the CD-ROM was always drive L. This way we always had 'room' to add HDs so there was no gap in the alphabetical sequence. Drive D - data drive, E - swapfile, etc.

Test and external drives (being temporary) were assigned letters further down than L. Sticking reasonably rigidly to this nomenclature avoided stuff-up such as cloning an empty drive onto one with data on it (cloning was a frequent activity).

Incidentally, this rule applied to all machines, a laptop with HD would have C drive and L as the CD-ROM. Machines with multiple CD-ROMs would be assigned L, M and so on.

After C:, it really is just allocated in order.

Between CD/DVD drives, writers, Zip Drives, and extra hard drives, it wasn't unusual for a workstation to naturally end up with G: or H:, before mapped network storage became common.

> A was the first floppy drive, B the (typically absent) second floppy drive

As another commenter mentioned, when you didn't have a second floppy drive, A: and B: mapped to two floppy disks in the same floppy drive, with DOS pausing and asking you to insert the other floppy disk when necessary. Which explains why, even on single-floppy computers, the hard disk was at C: and not B: (and since so much software ended up expecting it, the convention continued even on computers without any floppy disk drive).

Stacker compressed volume ;)

DriveSpace, surely

Windows also has uuids. E.g.:

    \\.\Volume{3558506b-6ae4-11eb-8698-806e6f6e6963}\

Only if you have a broken kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.

> [ .. ] Inserting an USB drive before boot breaks booting.

Only if the machine's BIOS is configured to give bootable USB devices boot-order priority. So it's not about Linux -- in fact, the same thing would happen on a Windows machine.

Remember that in a properly configured Linux install, the boot partition is identified by UUID, not hardware identifier (in /etc/fstab). Consequently if you change a drive's hardware connection point, the system still boots.

Certainly doesn't for me. Skill issue.

I always saw it as two different mindsets for data storage.

One vision is "medium-centric". You might want paths to always be consistently relative to a specific floppy disc regardless of what drive it's in, or a specific Seagate Barracuda no matter which SATA socket it was wired to.

Conversely it might make more sense to think about things in a "slot-centric" manner. The left hand floppy is drive A no matter what's in it. The third SATA socket is /dev/sdc regardless of how many drives you connected and in what order.

Either works as long as it's consistent. Every so often my secondary SSD swaps between /dev/nvme0 and /dev/nvme1 and it's annoying.

Windows drive letters are also linked to some partition UUIDs, which is why you can move a partition to a different drive, or move drive to a different address (change SATA/m.2 port)

You can use mountvol command to see the mount-letter/GUID mapping.