It’s all learnable and everyone starts somewhere. But you’d think natural curiosity would kick in and they’d have picked up some of this on their own by the time they have a job.
So 7zip and Winrar?
I joke, but only halfway. If you're only normal Windows user, you'd never hear of anything else (unless you want to go back to Winzip, which does still exist, but I've never heard of anyone using it any more).
But here’s one I heard literally two days ago: we counted three engineers (out of many) who knew that physical memory was not actually a giant flat space of contiguous addresses, and that there were multiple layers of address-mapping and region-joining glue logic between a program and the hardware, including in os libraries, and even inside the hardware.
Maybe knowing such information is archaic or useless for most engineers. But the good ones (or at least a certain flavor of the good ones) ask questions that lead them there.
That's the abstraction I'm working with when coding. Which is necessary because in most cases this should be an implementation detail.
It's all a layer below even OS programming. It's configured at the BIOS level and then performed in hardware. But that's the point, isn't it? Virtual memory is below the application programmer, too, but here we're chastising him for not understanding it. If we do that, shouldn't we equally chastise people for not understanding physical memory? Or speculative execution? Or head seeking and servo tracks? Or Ethernet line coding?
I also could no longer tell you how to balance a binary tree or implement Quicksort.
Worse, people who find it within themselves to ask questions anyway frequently face silence or a smackdown. The Internet's Own Boy remains no longer with us.
And I’ve hosted my own web server these last 20 years.
You spelled "frightening" wrong.
I've got a friend, I'll call him Bob, mostly because Bob is nowhere near his real name and I'm about to say some not very flattering things about him. He is my friend and not my job colleague or anything, so there's certain objectivity to this, in fact I appreciate Bob and I wish nothing but the best for him.
Bob has been programming for a bit more than a decade. He is, barring the people I know from other countries, the best paid programmer I know, and I know well over a dozen.
Bob has no interest whatsoever in any programming language that is not what he has been using his whole career, nor does he have any interest or curiosity in dipping his toes in other related fields, web development, tinkering with arduinos, home servers... Nothing. Bob has not built a computer, ever, doesn't know how to do it, nor what each part in that object does, beyond the hard drive because he did plug an extra one once or twice.
More anecdotally I played some Factorio and Satisfactory with Bob, now I know these are not excellent representations, but I expected a degree of order, planning and foresight, I was very much surprised when facing the reality of none of that being present, and I very much did not expect to see the same thing the few times I've looked at his code, but I did see that same thing.
I promise you Bob doesn't make up for all of this in social skills.
Now, is Bob a good engineer? I really, really don't think so. Is he a curious person? A bit, not much, I get the feel he just ended in CS with no particular interest for it, but I'll say it again: He is the best paid programmer I know.
Is that frightening? Well yeah, in a way. It's also endearing in a "Well damn if this guy can do it then surely I can too" sort of way. Money is not everything of course, but it's as good of a proxy as any.
Files aren’t sacred. It’s actually troubling that many technical people never consider alternatives. Most of the worlds data today is probably not stored in filesystems, rather in databases and object stores that use custom storage backends.
You know what, these big databases and object stores are living on bog standard but scalable filesystems most of the time. Ceph, ZFS, Lustre, etc., and sharded/stored as files. There are some very high performance and bespoke systems out there [0], yet they also provide POSIX compliant filesystem views outside, not because they are sacred, but because it works.
Filesystems provide great utilities for making abstractions other than files, by using files as universal containers you can play with. Again, while they are not sacred, they are an important building block, and they're here to stay. Creating a custom storage backend, throwing away all filesystem stuff is a fool's errand, since filesystems handle much more than providing a tree and some attributes on that file/folder hierarchy. Since they are the first level on top of physical storage devices, they also take care of the device underneath them (e.g. TRIM, FFFS (Flash Friendly File System), etc.).
It's a great irony that E-Mails are already stored as human readable databases on disks.
[0]: https://docs.weka.io/4.3/weka-system-overview/filesystems
And I’m complaining about technical and non-technical users who don’t understand why object stores (and web servers, and ftp servers, and archives) aren’t file systems just because they can hold files.
And don’t get me started on documents. Document object models can be so much more when they’re not just treated as a sequence of bytes.
But the most obvious alternative to a filesystem would be formatting a whole hard drive as an sqlite database. Obviously it would be a radical rethink in OS design.
There are also "single-level stores" from the last millennium - designs where there is no separation between volatile and nonvolatile storage. All memory in these systems is treated as nonvolatile. A Word document, for example, would be something like a suspended Word process. A directory is a process that only manages pointers to other files and directories. Obviously processes must be extremely lightweight in such a system. KeyKOS is an example of this and you can read papers about it and its Unix emulation layer. This is one of the many things humanity explored before settling on the hierarchical filesystem as the base layer of storage.
If you're asking how something other than the sqlite database Chrome profile data is stored in would prevent the intended behavior of deleting corrupted files silently, obviously the two issues are orthogonal. But a file-based system would mean a corrupted file (the others untouched) rather than a corrupted database (everything is gone). I'm horrified at the idea of replacing my resilient, inherently modular set of files with a brittle monolithic database.
At the end of the day, you'll be chasing pointers inside that SQLite database, where you store tables, indexes and such. Interestingly, this is how a filesystem works. Tables, indexes, redirections and fields. Very much like a database. EXT4 is a table of redirections, nothing fancy [0].
[0]: https://blogs.oracle.com/linux/understanding-ext4-disk-layou...
It's not that the average user is ignorant of the many ways in which data can be stored and retrieved. It's that they are becoming ignorant of such abstractions existing altogether. It's hard to start thinking about how images are stored if all the user knows is "they are in the gallery".